谷哥 — 应用 AI · 架构 · 遗留系统现代化

职业时间线 — 展开职位，查看代表性工作

2013 现职

大型企业软件公司 — 资深软件工程师 · 应用 AI 展开 ▾ 收起 ▴

加拿大温哥华 · 2013.12 — 至今

负责大型运输管理软件的后端架构、API 与框架设计，以及应用 AI。我善用 Cursor、Claude、Codex 等工具加快调研、原型和交付，同时始终由工程师承担技术判断、验证与责任。下面这些工作，大多是和最终负责它们的团队一起完成、并交到他们手里的。

    AI 交付 闭环工程 —— 越过"提示词"的那一步  基于这个想法做出了 TaskFlow —— 一个内部工具：说出目标之后，它自己走完规格、实现、测试、评审，而我被问到的是"要不要这么定"，不再是"下一条提示词写什么"。   大多数人是把 Cursor 当 IDE 用的，靠不断提示来推进：描述、审阅、纠正、再来一遍。而当我下沉一层、直接对着它的 SDK 工作时，约束条件看起来完全不同 —— 真正的瓶颈不是单条提示词写得够不够好，而是每两步之间都必须站着一个人。更好的提示词和 skills 能缩短每一步，却消不掉步与步之间的那些缝。于是我从底层把问题拆开：先是提示词，再是每个角色拿到的上下文，然后是它运行其中的承载层，最后才是把它们串起来的闭环 —— 谁交给谁、交接时必须带上什么、每个角色被禁止做什么。杠杆就在最后这层，而这一层几乎没人在做。
 提示词 写得更好能让每一步更好。但下一步仍然要人去触发。 
 上下文 每个角色有自己的模型和彼此隔离的上下文 —— 写规格的 agent 不会背着它本不该看到的实现细节。 
 承载层 与其重造运行时，不如让每个 agent 都是通过 SDK 驱动的真实 Cursor agent 会话 —— 装好的 skills 和 MCP 服务器原样可用，上游每次发版都白赚。 
 闭环 缺失的那一层：角色之间带类型的交接、把权限围起来使某个角色无法抢跑、以及会为自己预约唤醒而不是空转的 agent。人从这里开始不再充当调度器。 
 成效 基于这个想法做出了 TaskFlow —— 一个内部工具：说出目标之后，它自己走完规格、实现、测试、评审，而我被问到的是"要不要这么定"，不再是"下一条提示词写什么"。 
   产品 下一代产品 —— 是设计出来的，不是搬过来的  仪表盘做到了功能完整的生产候选版；调度计划模块补上了产品里一处显眼的缺口，快到足以摆到客户面前 —— 两者都不是它们所取代的那块旧界面的复制品。而随之引入的 AI，成了产品后续 AI 工作的起点。   这个 Web 产品，是一套在客户现场跑了几十年的桌面系统的下一代。而这类项目最省事的做法是"平移"：把每一个 Windows 界面在浏览器里重画一遍，然后发布。这样做出来的东西用户认得，但不会有人为它兴奋。我加入时在这条产品线上没有任何积累，六个月内设计并交付了地图优先的实时运营仪表盘，随后又主导了新调度计划模块的设计与开发 —— 这两样在桌面端都不曾以这种形态存在过。真正需要判断的是：哪些能力值得带到下一代、哪些习惯值得推翻、以及新技术究竟在什么地方真的改变了一块屏幕能做的事。
 设计出来的，不是搬过来的 桌面上的每一块界面都可以一比一搬过来 —— 那个版本上线更快，也在上线当天就过时了。真正起作用的判断发生在写代码之前：谁在用这块屏幕、他最先伸手去够什么、旧页面的哪些习惯值得打破。AI 把"一个想法"到"一块能立刻做出反应的界面"之间的距离压得很短，设计与实现于是不再是两个阶段。 
 仪表盘 用一个实时工作台取代多年的静态表格页：GPU 加速密度图、动画路线轨迹、渐进式加载 —— 5000 条记录流式载入时，1–2 秒即见有效信息。17 个可复用资源模块，意味着未来新增视图无需改动已有视图。 
 调度计划 主导新计划模块的设计与开发，把一个被描述出来的需求，做成产品里真正可用的一块。 
 快是设计的一部分 1–2 秒不是事后做优化调出来的指标，而是决定这块屏幕值不值得做的前提：延迟一旦越线，实时运营视图就退化成又一个表格页。所以加载策略是和版式一起设计的，不是后来补上去的。 
 扛得住产品考验的 AI 现在几乎任何人都能在一个下午用 AI 做出一个惊艳的演示。难的是判断这些能力里哪一个经得起产品的考验：哪些可靠到能摆在一个以速度论绩效的调度员面前、哪些出错时能安全降级、哪些必须留在人的控制之下。我做演示是为了找出答案，然后拿真正扛住的那部分去做产品。这也是我在产品还没有任何 AI 时就把它放进去的原因 —— 它确定了 AI 在这里站在什么位置、被允许决定什么。 
 成效 仪表盘做到了功能完整的生产候选版；调度计划模块补上了产品里一处显眼的缺口，快到足以摆到客户面前 —— 两者都不是它们所取代的那块旧界面的复制品。而随之引入的 AI，成了产品后续 AI 工作的起点。 
   AI 多智能体发票校验 —— 原型就是需求文档  每单审核约 3–5 秒，比人工审核快 95% 以上；结业项目得分 98%。同样重要的是，从原型到可上线的那一版，几乎没有推倒重来的部分。   发票审核又慢又不齐整，因为规则散落在文档措辞和老员工的经验里，从来没进过任何规则引擎。我没有先去写需求说明，而是直接做了一个跑得起来的东西 —— 搭在当前版本已经对外提供的 API 上 —— 然后把它摆到真正做这件事的人面前。跟一个能跑的系统争论，比审阅一份文档有效得多：需求是以"这里判错了"的形式回来的。而由于它站在已发布的 API 上、而不是临时搭的架子上，从这个原型到第一版可上线产品之间的距离很短。这才是我在意的部分 —— 没法产品化的原型，只是个演示。
 痛点在哪 订单与发票的规则写在文字里，也装在资深员工的脑子里。核对全靠人工，慢，而且不同的人审出来不一样。 
 不要规则引擎 DSL 让智能体直接读自然语言写的业务规则。改一条规则是改一句话，不是发一个版本 —— 正因如此，产品还在定义阶段时，规则可以一直动。 
 建在已发布的 API 上 原型调用的就是已发布产品对外暴露的那套 API。要让它变成真的，没有任何东西需要重写，通常那道"原型到生产"的坎从一开始就不存在。 
 用原型代替需求访谈 用户纠正的是一个能跑的系统，而不是审阅一份需求文档。指着一个错误的结果说"这里不对"，比事先描述一条需求精确得多。 
 它是怎么跑的 智能体并行执行、行为由配置驱动、整条 LLM 链路端到端可观测，便于排查问题与满足合规要求。 
 成效 每单审核约 3–5 秒，比人工审核快 95% 以上；结业项目得分 98%。同样重要的是，从原型到可上线的那一版，几乎没有推倒重来的部分。 
   黑客松 公司黑客松 —— 整个 demo，一个人，掐着表做完  连续三年，三个能跑的原型，每一个都按时完成并完成演示 —— 而每一次其实都是在排练同一套循环：找到一个真实的痛点，做出一个真的跑得起来的东西，拿到有这个问题的人面前。   公司的黑客松，每办一次我都报名。多数人是组队参赛的，那也是更稳妥的做法 —— 我是有意选择一个人上 —— 不是因为偏好单干，而是黑客松是唯一能把自己的判断从头到尾检验一遍的地方。分工会让死线好过很多，但我能学到的也会少很多。一个人意味着选题、架构、实现、幻灯片、演示视频、现场讲解，每一样都得我自己做对，于是一个产品的完整弧线 —— 从"挑一个值得解决的问题"到"让它跑给人看" —— 被压进几天之内。这是我能拿到的、关于自己判断力最快也最诚实的反馈，也是唯一一个什么都甩不出去的场合。
 2023 用函数调用让智能体直接查询并操作平台自己的运营数据 —— 那时"工具调用"和 MCP 这类说法距离成为通用词汇还有好几个月。 
 2024 AI 配合本地知识库，给夜间值班的支持来电做分诊。选题来自我自己的 on-call 轮值：那个痛点是我本人半夜被叫醒过的。 
 2025 为 SaaS 迁移做应用层遥测，基于 Azure Application Insights。它搭在已有的共享库架构上，所有应用无需改代码即可上报，且没有可测量的性能损耗 —— 实现上是单例配合异步批量发送；另外做了分析工作簿，把原始事件变成产品与迁移负责人能直接读懂的答案。 
 选择了全部自己扛 想法、架构、代码、幻灯片、演示视频、旁白、现场讲解。既然选了全部自己扛，唯一能按时落地的办法就是从"演示的那一刻"倒着往回排计划 —— 而这套排期的纪律，正是我带回日常工作里最多的东西。 
 成效 连续三年，三个能跑的原型，每一个都按时完成并完成演示 —— 而每一次其实都是在排练同一套循环：找到一个真实的痛点，做出一个真的跑得起来的东西，拿到有这个问题的人面前。 
   遗留系统 遗留系统 —— 总能找到切入点  在同一个产品上做了十二年，从未提议过重写。上面每一件都保持周边系统原样不动，却拿掉了人们早已当成"本来就这样"的工作 —— 而最近的一件，把 AI 放到了那层本被认为碰不得的技术栈上。   这个产品的大部分比我资历还老：Windows 桌面程序、DB2 存储过程、在 SOAP 还是主流时写下的集成。面对这类软件，常见的两种反应是"别碰它"或者"建议重写"，而这两种通常都不对。十二年里真正有效的做法要窄得多 —— 找到旧系统真正在消耗某个人时间的那一个点，把新东西恰好放在那里，其余原封不动。系统不需要被重写才能变好，它需要被理解到足够深，深到你知道新的那块该嵌在哪。
 2013 · 第一件事 入职第一个月我发现：系统能发邮件，却没有任何地方能看到自己发出去过什么。我做了一个仿 Outlook 的查看器补上这个缺口；因为封装成了共享库，它最后进了每一个与邮件相关的模块 —— 后面所有事情都沿用了这个路数。 
 2015 · 让一处集成不再疼 第三方保险监控集成每升级一次，就意味着一轮数据库改动、界面改动和单向同步逻辑重写。我围绕动态界面、可配置且向后兼容的同步、以及扩展点重新设计，使得下一家供应商变成一次配置，而不是一个项目。 
 2017 · 领先一代 当整个生态还停留在 SOAP 和直连 ODBC 时，我主导了基于 DB2 存储过程的 REST 框架，其中的查询端点理论上可服务任意表或视图。新查询接口的开发从数天缩短到数小时，集成方也从裸数据库连接迁到了标准 API。 
 2019 · 拿掉一个二十年的人工环节 横跨九个子资源的 EDI 订单更新，二十多年来一直靠人工核对与处理。我设计的比对-更新引擎既能在界面里供人工审核，也能在服务端无人值守运行。 
 2022 · 消化掉 3000 小时 一个三层嵌套的 API 项目被预估为 3000 多小时。我把重复结构抽象出来：一份 JSON schema 定义 POST 模型，PUT 与 DELETE 支持随之自动获得，开发者只写业务逻辑。多个接口的交付时间少于原先单个接口的预估，培训后其他开发者也开始使用。 
 2023–25 · 把 AI 放到最老的那一层 SQL 优化器就架在这套技术栈上。我最初的自然语言生成 SQL 演示被否掉了，理由是风险太高 —— 而这个质疑是成立的。把它反转过来才做得成：让 AI 读已有 SQL、库表结构和 DB2 的执行计划，给出带推理的建议，决定权留给工程师。最终基于 Azure OpenAI 三阶段流水线上了生产。 
 成效 在同一个产品上做了十二年，从未提议过重写。上面每一件都保持周边系统原样不动，却拿掉了人们早已当成"本来就这样"的工作 —— 而最近的一件，把 AI 放到了那层本被认为碰不得的技术栈上。 
   跨团队 跨团队交付 —— 交还，而非交差  从零领域知识到生产就绪的流水线并完成交接，约四个月 —— 而现在拥有它的团队，并没有继承一份"离不开我"的依赖。   我被从自己的团队抽调出去，帮另一个团队做云端记账集成，而那套生态我一无所知。这种事没有"以访客身份待着"的有效版本。摆在面前的是四个月、横跨四个架构层的七个系统，以及分布在几个组里、各自只掌握其中一块、没有人掌握全貌的同事。所以第一件事是让自己变成一个他们可以跟你争论的人 —— 把他们的领域学到足以做设计，而不只是照着做。而最后一件事更重要：把归属权交还得足够彻底，让这个团队没有我也能继续扛下去。
 没有适应期 进去时对这套生态零认知，必须快到能做架构判断，而不是等着别人告诉我该写什么。 
 七个系统，四个层次 本地系统与暂存表、云端门面 API、由调度与增量服务构成的核心层（其下是 MongoDB 集合与 Kafka 主题），以及 OAuth2 之后的目标记账服务 —— 每一块分属不同的组。 
 做出来的是什么 一条事件驱动的总账批处理流水线：批次自动发现、无需人工触发；九状态的批次生命周期；带账务维度解析的动态转换；重复检测与幂等操作；令牌缓存与自动续期；以及完整的审计链。 
 进度是能看见的 每个里程碑我都录成演示视频，而不是写成进度汇报 —— 从本地变更捕获模拟一直到端到端全流程导出。当相关方分散在多个团队里，"一个能跑的东西"是唯一不会被误读的进度报告。 
 交接本身就是交付物 归属权完整交还给了往后要靠它过日子的团队，知识交接按期完成。被借调这件事，只有在借调结束时才算值得。 
 成效 从零领域知识到生产就绪的流水线并完成交接，约四个月 —— 而现在拥有它的团队，并没有继承一份"离不开我"的依赖。 
 

Applied AIAzure OpenAIREST APIPythonC#ReactKafka

2009

Entrepôt du Nord— 资深软件架构师 / 全栈工程师展开 ▾ 收起 ▴

魁北克 Laval · 2009.03 — 2013.12

从零架构 IntelliNord 全栈仓储运营套件，横跨桌面软件、后台服务、Web、外部集成、移动设备、数据库、计费和生产基础设施。

    系统 IntelliNord —— 跨越完整技术栈的仓储运营平台  建立了连接仓库现场执行、客户可见性、自动集成、合规、计费与财务的共同技术基础。   IntelliNord 并不是一个单独的 WMS 程序，而是一套运行在多种环境中的完整产品体系。我直接与公司负责人合作，把仓库作业、客户服务、合规和计费流程转化为彼此连接的软件能力；责任范围从界面与业务逻辑延伸到数据库、外部集成、服务器部署和长期生产维护。
 桌面运营系统 使用 Delphi 开发 Windows 应用，承载收货、库存、出货、检查以及仓库控制等核心作业。 
 定期与后台服务 无人值守的定时程序负责数据同步、交换处理、输出生成和周期性业务，让日常流程无需人工反复启动。 
 计费与账务连接 灵活的计费子系统通过 Advantage Database 存储过程提速 —— 约为旧系统的 30 倍，并逐步连接外部账务平台。 
 Web 实时访问 PHP 与 .NET 网站为客户和员工提供最新库存、收货、出货、标签、铅封和检查信息。 
 FTP 与 EDI 自动化 按照不同客户的数据格式与运营要求，自动处理入站和出站业务交换。 
 移动仓库作业 从 Windows Mobile 迁移到 Honeywell Android，设备平台整体更换而收发货未曾中断；在冷库现场完成实时扫描、签名、受损产品拍照和异常记录。 
 合规与报表 将包括 Trichina 相关检查在内的 CFIA 流程纳入日常仓储作业，并生成可追踪的运营记录和报表。 
 部署与长期支持 负责服务器配置、生产发布、环境维护和问题排查，并随着业务与技术变化持续演进整套系统。 
 成效 建立了连接仓库现场执行、客户可见性、自动集成、合规、计费与财务的共同技术基础。 
   集成 与企业级平台的集成  运营、计费、财务与集团报表保持同步，系统之间无需人工重复录入。   仓库从来不是孤立运转的：计费、财务和集团报表各自依赖不同的大型外部系统，每一个都有自己的数据模型、协议和故障方式。我设计并长期维护这些集成，让 IntelliNord 与它们保持一致 —— 数据在仓库现场录入一次，就能到达所有需要它的地方。
 ADVANTAGE 基于 Advantage Database 存储过程重建计费，收费更准确、更灵活 —— 速度约为旧系统的 30 倍。 
 WORKDAY 将开票流程与 Workday 相关财务流程打通，保证计费与财务账目一致。 
 METRICSONE 通过 metricsOne API 自动上报仓容与利用率数据，取代人工上传。 
 成效 运营、计费、财务与集团报表保持同步，系统之间无需人工重复录入。 
   云端 在遗留内核上长出云端归档 —— 什么都没重写  历史数据同时变得安全、卸载、可查询 —— 而卸掉多年历史的生产库，始终保持小而快。审计不再和生产运营抢资源，遗留内核照旧运转，一行未改。   多年的交易历史压在遗留数据库里，两头不讨好：审计要在生产表上慢慢扫，而唯一的备份就是数据库本身。我没有去动内核，而是向上扩展：归档交易数据流入 AWS DynamoDB —— 刻意选了键值存储而不是关系型数据库，因为归档查询天然是按键取数，从不需要关联 —— 再由一层 AWS API 随时把数据取回来。仓储系统毫无感知；云端只是围绕着它生长出来。
 为什么是 DynamoDB 归档查询问的是"这张订单、这个托盘、这个日期段" —— 是键查找，不是关联。NoSQL 表正好匹配这个形状，扩容不用调优，闲置时几乎零成本 —— 而归档大部分时间就是闲置的。 
 随时可查的审计轨迹 过去要在生产库里翻找的审计与历史问题，变成对云端归档的快速 API 查询 —— 任何时候都能回答，也不再拖累运营系统。 
 本地系统反而更快 卸载历史不只是为了上云：多年归档移出生产库之后，本地数据量始终很小，查询始终很快，系统跑得很轻 —— 归档在云端不断增长，仓库现场却毫无感觉。 
 会回答问题的备份 批量上传到云端的历史数据不是冷存储里的死副本：保护数据的存储同时对外提供查询，备份自己养活自己。 
 无缝是设计出来的 一边是 AWS 的现代服务，一边是遗留的仓储内核，接在一起而互不知晓 —— 和上面每一项同一个模式：把新东西放在恰好值得的位置，其余原样不动。 
 成效 历史数据同时变得安全、卸载、可查询 —— 而卸掉多年历史的生产库，始终保持小而快。审计不再和生产运营抢资源，遗留内核照旧运转，一行未改。 
 

WMSDelphi.NETPHPAndroidEDICFIAReactAWSWorkday

2003

The 3rd Eye Tracking — 资深架构师 / 创始技术负责人展开 ▾ 收起 ▴

魁北克 Dorval · 2003.05 — 2013.12

创始技术成员：从现场设备往上，把公司的追踪产品整个建起来 —— 硬件、通信、客户登录进来看的那张实时地图，以及公司自己赖以运转的系统。

从零到一从追踪硬件，到一张谁都能打开的实时地图公司的产品实质上就是这套技术：我们验证过的设备、它们上报进入的平台、客户登录去看的那张地图，以及给他们开账单的计费系统 —— 全部从零自建。

那个年代的车辆追踪，基本等同于"被偷之后找回来"：你打电话给服务商，他们配合警方去找车。没有人提供那件最平常的事 —— 让车主自己随时看一眼车现在在哪，不用向谁申请。我们做的就是这个：浏览器里的一张实时地图，基于 Google 的地图 API，而当时把一张会动的地图嵌进商业应用里还是件新鲜事。我是创始技术成员，这张地图底下的所有东西都由我来建。

缺口在哪: 找回服务回答的是"我的车被偷了"。没有人回答"我的车现在在哪" —— 而后者是一支小车队每个工作日都要问的问题，也正是当时的大厂商在结构上没打算服务的。
一张实时地图，在那还很新的时候: 位置、行驶轨迹、电子围栏、超速与报警提醒，都在浏览器里，随时自己看，无需等人。网页地图刚刚变成开发者能嵌进去的东西，所以光是把"它在动"演示给客户看，销售就完成了大半。
为谁而做: 小型车队，以及需要盯住某一台特定车辆的车主 —— 他们小到不足以让当时的大厂商上心，却恰恰是最想随时看一眼的人。
地图底下是什么: 追踪设备的评估与实地测试、通过 TCP/IP 与 UDP 的接入，以及一个多线程 VB.NET 服务：基于数据驱动的组件化框架，同时承载大量设备。此外还有客户端到调度的消息、远程布防撤防、群组告警与无线追踪，可扩展的报表子系统、多语言数据模型，以及公司自己用来运转的库存与计费系统。

成效公司的产品实质上就是这套技术：我们验证过的设备、它们上报进入的平台、客户登录去看的那张地图，以及给他们开账单的计费系统 —— 全部从零自建。

ArchitectureVB.NETTCP/IPUDPPHPMySQLSQL Server

2000

ET-CHINA.COM — 资深开发架构师 / 项目负责人展开 ▾ 收起 ▴

中国广州 · 2000.11 — 2003.04

负责在线机票预订与查询系统，以及早期移动服务的架构和交付，涵盖需求分析、技术规划、项目推进与开发辅导。

移动端移动互联网早期的实时机票预订服务很快铺开，成为当时许多商务人士使用手机订票的优先选择。

当手机数据通信刚刚起步时，我参与开发 WAP 订票应用。Java 后台接口直接连接实时航空订座系统，保证查询与预订的速度和准确性；手机端界面保持简单，让用户无需电脑即可查询余位并完成订座。

成效服务很快铺开，成为当时许多商务人士使用手机订票的优先选择。

平台一体化机票预订与查询平台为国内互联网市场快速发展阶段的在线旅行预订，建立了可实际落地的技术基础。

参与架构和开发 ETC 在线预订与查询界面，串联航班可用性、时刻表和预订流程；同时参与版本规划、技术评估，并辅导其他开发者。

成效为国内互联网市场快速发展阶段的在线旅行预订，建立了可实际落地的技术基础。

JavaWAPReal-time APIsE-commerceBooking Systems

1997

中国建设银行 — C/Unix 开发工程师展开 ▾ 收起 ▴

中国广州 · 1997.07 — 2000.10

负责企业银行客户端、服务端、报表与单据打印模块的开发和维护（C / Unix）。

自动化用模板化打印取代手工定位显著提升了银行报表和客户单据打印的效率与准确性，并减少了重复的人工设置。

我发现报表、存折和存单打印高度依赖人工定位与反复调整，既耗时也容易出错。于是自行编写模板化打印工具：版式只需定义一次，后续即可按模板稳定生成，无需每次手工校准。

成效显著提升了银行报表和客户单据打印的效率与准确性，并减少了重复的人工设置。

平台 Unix 上的企业银行系统打下了在高要求业务流程中构建可靠、注重细节的软件系统的基础。

参与客户端银行功能、服务端服务和报表模块的开发，运行于 Unix 终端、HP-UX 服务器与 Informix 数据库环境。

成效打下了在高要求业务流程中构建可靠、注重细节的软件系统的基础。

Unix 上的企业银行系统 —— C · HP-UX · Informix · 模板驱动打印

CHP-UXInformixBanking

1993

华南师范大学 — 计算机科学学士

中国广州 · 1993 — 1997 · GPA 3.78/4.00

一切开始的地方。

业余造物

工作之外持续开发的软件项目；准备就绪后会陆续在这里发布。

开源 · Web展开 ▾收起 ▴

AgentMux

让 Cursor、Codex、Claude Code 在同一个项目上并肩跑 —— 并行 tmux 会话，一页浏览器。

github.com/chatpoc-ai/agentmux ↗

起因是一张账单：我订阅了不止一个 AI 编码 agent，却还在一个一个地用。AgentMux 让它们一起跑 —— Cursor Agent、Codex CLI、Claude Code，各自在同一个项目目录的独立 tmux 会话里 —— 所有终端流式汇聚到一页浏览器。把同一个任务发给三个 agent，看它们思路差多远；或者拆开任务并行推进，用手机盯着进度。完全开源。

并肩运行: 每个 agent 在自己的 tmux 窗格里对着同一个项目跑。同一任务发给三个，比较各自的思路；或者不同任务并行 —— 多路复用正是意义所在。
一页，任何设备: 终端通过 WebSocket 流式进浏览器，每个窗格带实时活动状态。同一网络下手机就能打开 —— 看进度不再需要坐在桌前。
会互相说话的 agent: 一个小小的包装命令让窗格之间可以互发消息、向上汇报进度 —— 并行会话能够协作，而不只是共存。
重启也不丢: 会话活在 tmux 里，不在服务进程里 —— 服务器重启，每个 agent 的对话都还在。
工程: Node.js、Vite、xterm.js，零原生依赖。中英文文档齐全。

私有 · Web展开 ▾收起 ▴

TradeLab

自托管交易工作台：两个 AI 模型就每一笔机会互相辩论，最终由确定性代码决定它能否走到券商那一步。

一套跑在自己服务器上的交易工作台，核心只有一条原则：模型负责推理，但从不负责决定。每根 K 线收盘，TradeLab 截下三个周期的图，汇总数值上下文 —— 波动率、市场状态、筹码分布、多周期趋势 —— 交给两个互相独立的 AI 模型，按固定策略各写一份判断。返回的从来不是订单，而是一份提案；它必须先通过一连串确定性检查，代码才被允许把它发出去。每一份判断都在结果揭晓之前落盘，之后再拿真实走势去核对。自托管、单用户：日记、账户连接与策略都在自己的硬件上，而不是在别人的产品里。

两个会吵架的模型: 主笔模型写出判断；另一个上下文完全独立的模型拿到同样的图表和主笔的答案，被明确要求真的去反驳。主笔再据此收敛，结果带一个"是否达成共识"的标记 —— 分歧被摆出来，而不是抹平。
AI 不能下单: 它只能提议。缺少触发价、止损或目标的判断会被自动降级为中性；活下来的还要通过价格次序合理性、最低 1.5 的盈亏比、不小于 2 倍 ATR 的止损、动态最小风险距离、高周期方向闸门和信心闸门。最终拍板的是确定性的 Python，不是模型。
关 / 纸面 / 真钱: 真钱默认关闭，且按品种单独启用。纸面模式会完整记录"本该发出的那一单"，但什么都不发。真钱模式下的是微手数的括号单，同方向只留一个仓位、有累加上限、久未成交的挂单自动过期。
持仓有人盯着: 一个"管家"会遍历账户上每一笔在途持仓和挂单 —— 包括你直接在券商 App 里手动开的 —— 按 1 倍 ATR 移至保本、时间止损、只收不放的追踪止损、以及对陈旧挂单重新定价。它被刻意设计成只给建议：按钮始终由你来点。
回放用的是同一个大脑: 既可以让会话在历史里逐根 K 线推进、手动下单，也可以跑前推式回放 —— 每个检查点调用与实盘完全相同的分析流水线。回放不是简化版：它和实盘想得一样久，所以在回放里学到的东西是能迁移的。
它给自己打分: 每一份判断都会拿真实走势去核对，按来源分别统计命中率，再把这条校准结果写进下一次的提示词里 —— 让模型知道自己过往有多可靠。交易规则也一视同仁：手册为每条规则标注实测结果，长期亏损的规则会被停用。
为方法而做的图表: 三个周期联动，筹码分布带分位区间，ATR 与市场状态判定，自动趋势线拟合，支撑阻力区识别。多周期上下文会刻意丢掉尚未走完的高周期那根 K 线 —— 回放的检查点因此永远看不到未来。
能闭环的交易日记: 数千张分析卡连同截图存档，每张带着当时的判断，以及结算后的结果、进出场价和 R 倍数。定时的日报与周报会把它们读回去，标出哪些交易忠于策略、哪些是临场发挥。
覆盖的市场: 外汇、贵金属、股指与商品差价合约通过券商接口全流程可交易。美股与中国 A 股接的是行情、选股和带结果验证的 AI 选股日记 —— 是分析与记录，不是下单通道。
工程实现: Python + FastAPI，约 96 个接口和四条后台循环；React + TypeScript 工作台，基于 TradingView 图表；没有数据库 —— 全部是本地磁盘上的 JSON。下单 I/O 收在一层券商接缝之后，决策逻辑并不知道自己在跟哪家券商说话。
跑到出问题才有的东西: 针对被限流模型的熔断器、智能体会话卡死后的自愈、绕开已知文件描述符泄漏的进程回收，以及一次由"每次追加都要重写 3.8MB 文件"的实测数据推动的存储重构。好几条策略规则直接注明了催生它的那笔真金白银的交易。

开源 · Web展开 ▾收起 ▴

ChatPOC

一个免费的 AI 工具：一次对话，把想法变成能跑的概念验证 —— 先出需求文档，再出代码。

020idea.com ↗

大多数想法死在"我能说清楚"和"我能演示"之间的那道缝里。chatPOC 补上它：网站是前台 —— 你描述想法、回答 AI 反问的问题；后台是一条流水线，调度多个 AI 工具，产出一份需求文档和一个能跑的原型。免费，不用注册。流水线的产出发布在下面那个开源账号里。

前台 + 流水线: 对话是界面，构建是流水线。需求在对话中澄清、固化成 PRD，然后后台调度多个 AI 工具生成原型 —— 和做产品一样的纪律：需求先于代码。
免费，无需注册: 不用注册账号。工具本身以 MIT 协议开源在 GitHub。
语言: 英文、简体与繁体中文、日文、法文。

开源 · GitHub展开 ▾收起 ▴

开源账号

我公开代码的家 —— 一个长期维护、持续增长的原型与个人项目集合。

github.com/chatpoc-ai ↗

刻意只用一个账号：我公开的代码都落在这里，而且是长期打理，不是一阵热闹之后就荒掉。目前它承载着 chatPOC 工具、十九个流水线构建的原型，以及 AgentMux —— 第一个搬进来的个人项目，后面还会有更多。

广度: 十九个 TypeScript 原型横跨完全不同的领域 —— 安防监控、量化交易平台、离线优先的教育应用、病理质检、纸牌游戏、VR 画廊。广度正是重点：同一套工作流，不挑领域。
长期: 新原型持续落地，账号按生产代码的标准打理 —— README、协议、更新。一个持续维护的账号，比一个推完就不管的仓库更能说明问题。
接下来: AgentMux 就是这个模式的开端：个人项目在各自准备好后陆续搬进来，是否开源逐个决定。这一页和那个账号会一起生长。

App Store展开 ▾收起 ▴

Emergency Binder

为家庭应急文件准备的安全收纳空间，便于分类、加密保存和随时查找。

App Store ↗

很多老人都备着一个应急文件夹：病历卡、保险单、重要联系人 —— 万一突然住院，家人照着它就能处理。但纸质文件夹越攒越厚，不防火不防水，而且只能放在家里。Emergency Binder 把它搬进老人随身的手机：拍照或口述录入，加密保存、分类整理，关键时刻能安全地交到家人手上。

为长辈而设计: 主页只有三个特大按钮 —— 扫描、查看、备份。默认字号 120%，可调至 150%，每个主要界面都内置分步帮助。
录入方式: 多页文档扫描（一次最多 50 页）、拍照与相册导入；描述可以语音口述转文字，任何记录都能附上录音。
加密: 照片与录音在保存前以 AES-256 加密，密钥存放在 iOS Keychain；支持 Face ID / Touch ID 解锁。
安全语句: 不用密码，用一句容易记住的话 ——「为了我爱的家人 2025」。大小写不敏感，锁屏可留提示语，让最容易忘记密码的人也进得来。
家人共享: 通过隔空投送、信息或文件导出加密包；家人输入你的安全语句即可解开，导入后自动改用他们自己的语句重新加密。
完全离线: 无服务器、无账号、无统计上报 —— 应用里没有任何联网代码。数据随 iPhone 的正常备份（iCloud 或电脑）一起备份。
整理与找回: 医疗、保险、家庭、财务等七类预设分类，可自定义扩展；支持搜索、每条记录的版本历史和回收站。
多语言: 英文、简体中文、繁體中文、法语、韩语。

App Store展开 ▾收起 ▴

Dual Cams

两颗镜头同时录制 —— 为拍摄体育比赛而生。

App Store ↗

一台摄像机拍不全一场冰球比赛：跟着攻防就丢了球门，盯着球门又错过推进。Dual Cams 让 iPhone 的两颗镜头同时录制 —— 广角跟住战局，长焦锁定球门；精彩发生时，在手机或手表上点一下，刚刚过去的画面就从两个机位各自存成成品片段。全部装备：一部 iPhone，架在稳定器和脚架上。

双镜头同录: 超广角、广角、长焦、前置任选两颗，各自独立设置分辨率（HD/4K）与帧率。每一种格式组合都先在真实硬件上验证可行才会提供 —— 某台 iPhone 到底能同时跑哪两颗，不该等到比赛开始才发现。
进球键: 录制中点一下即标记进球：两颗镜头继续录，同时把刚过去的 5–120 秒（时长可调）从两个机位各剪成成品片段。另有一个「精彩瞬间」键，两者分开归档 —— 一场球的进球始终能和其它值得留的镜头区分开。
锁定白平衡: 两颗镜头各自对同一片冰面测光，自动白平衡会逐渐跑偏，剪在一起时两个机位的颜色对不上。锁定会冻结当前测得的值；同步开关把主摄的设定推给副摄，再用 ±1500K 的偏移一起微调。
锁定 ISO: 球馆灯光会让自动曝光在关键回合中途来回试探。锁定即固定当前 ISO。双摄同步时，这个值会按副摄自身的范围重新收敛 —— 超广角和长焦的 ISO 上限本来就不一样。
A/B 预设: 每颗镜头存两组变焦值，或两个对焦点；在预览上向上或向下一划就能跳过去，眼睛不用离开比赛。录制中可用，两颗镜头各自独立设置，退出后仍然记得。
Apple Watch 遥控: 抬手就能开始/停止、标记进球、拍照、步进变焦 —— 手机全程不用离开脚架。
两个相册同时可见: 片段在同一次操作中写入系统相册和 DualCams 相册 —— 是同一份素材归入两处，不是复制两份；进球再额外收进专属相册。App 内的片段库读回时，进球标绿色球、其它精彩标黄色星，不必导出就能找到。
机位剪辑器: 在一组素材上打标记，剪辑器按广角 → 长焦 → 广角切换机位，每段可独立调速，从 0.25× 慢动作回放到 4×，导出前可完整预览。另有批量合并：取每个选中片段的末尾若干秒，把整场比赛串成一条集锦，画中画版式也在内。
下一版 · 直传 YouTube: 下一版将加入：登录 YouTube 账号，片段以断点续传的分块方式上传，按月自动归入播放列表，默认不公开，且默认仅 Wi-Fi 上传。每个机位各自上传为一条视频；想合成一条就先合并。
云台集成: 应用内直接蓝牙控制 OpenScope 云台的水平与俯仰 —— 整套设计正是围绕这套脚架装备。
真实拍摄打磨出来的: 只有真拍过一个赛季才会长出来的细节。标记键做得比录制键还大 —— 比赛里它按得频繁得多，戴着手套、来不及低头看。标记进球时会先等两路输出稳定并重试再重启，因为早期版本偶尔只恢复了一颗镜头。录制被来电打断时，文件会保存下来而不是丢掉。还有把比赛投屏到电视，会让 iOS 报告的屏幕方向失准 —— 这种问题坐在桌前是发现不了的。
工程实现: 100% 原生 Swift 与 SwiftUI，基于 AVFoundation 多摄会话，零第三方依赖；HEVC 与 HDR 全程保留；支持十种语言。

内测

Cheque Snap

在手机上填写个人支票，再准确打印到实体支票上。

内测

RouteTracer

学车练习助手：跟随考试路线，为新手提供类似考官的行车提示。

更多项目开发中

*.brogu.ca