elmagnifico | 云浅雪

2026-07-21 00:00:00

Foreword

CodeBind Docs 写完、VS Marketplace 也挂上去了，本以为 Cursor 那边搜一下就能装。结果发现：Cursor 扩展市场不跟 Microsoft 那套走，得另发一份到 Open VSX。下面把 VS Code 怎么发、Open VSX 怎么发、以及这趟踩的坑一起记下来，免得下次又忘。

两套市场

Cursor和VS Code的插件市场原本是一套，但是后来微软收紧策略，导致分开了，变成了2个市场。

Cursor 里有两套完全不同的「市场」，名字都带 marketplace

CBD 是正经 VS Code 扩展，跟 Cursor Plugin 那套无关。想让人在 Cursor 里 Ctrl+Shift+X 搜到，只发 Microsoft Marketplace 不够，必须再发 Open VSX。

官方也写明了：Cursor 第三方扩展走 Open VSX，中间再套一层他们自己的安全扫描代理。

VS Code 插件（Microsoft Marketplace）

官方文档：Publishing Extensions。下面按我实际走过的顺序记。

0. 扩展本身先能装

本地 npm run compile 过，扩展开发宿主里跑得起来；上架前最好再过一遍测试。打包工具用官方的 @vscode/vsce（老包名 vsce 别再用）。

package.json 至少这些要齐，缺了会拒：

另外 README、CHANGELOG、LICENSE 建议都有；市场页长什么样，基本看 README。CBD 还补了 keywords、categories、galleryBanner，好看一点而已。

扩展完整 ID = publisher.name，例如 codebind.codebind-docs。这个 ID 以后基本改不了，起名字时想清楚。

1. Azure DevOps 搞一个 PAT

Marketplace 认证挂在 Azure DevOps 上，所以要先搞 Personal Access Token：

1. 打开 Azure DevOps，用微软账号登录（跟后面建 Publisher 用同一个）
2. 用户设置 → Personal access tokens → New Token
3. Organizations 选 All accessible organizations（选成某个具体 org 很容易发不出去）
4. Scopes 勾 Marketplace → Manage
5. 创建后立刻复制，关掉就再也看不见了

这完全是Agent的说法，实际个人作者根本不需要，直接走下步即可

2. 创建 Publisher

1. 打开 https://marketplace.visualstudio.com/manage
2. Create publisher
3. ID：唯一标识，进 URL，创建后不能改（CBD 用的 codebind）
4. Name：市场上显示的名字，品牌文案，这个还能动

ID 别跟显示名搞混：ID 是机器认的，Name 是给人看的。

3. 打包 / 发布

命令行一把梭：

npm run compile
npx @vscode/vsce publish --no-dependencies
# CBD 仓库里等价于：npm run publish:vsce

publish 内部会跑 vscode:prepublish（一般就是 compile），再上传。

先打 .vsix 再网页传（更稳，出问题好排查）：

npm run package
# → codebind-docs-x.y.z.vsix

然后到 manage 页 → 你的 publisher → New Extension / 更新已有扩展 → 上传 .vsix。

本地试装：

code --install-extension codebind-docs-x.y.z.vsix

或命令面板：Extensions: Install from VSIX...。、

4. 更新版本时注意

• 改了 README 截图、描述、代码，都要 bump version，同一版本号覆盖不了
• unpublish 和「彻底删除」不是一回事；删除后名字可能被永久占用，慎用
• .vscodeignore 写清楚，别把 node_modules、测试产物、开发脚本打进包；反过来媒体、out/、README 别误忽略

CBD 这边 VS 市场页：

https://marketplace.visualstudio.com/items?itemName=codebind.codebind-docs

Token

拿token，需要先新建一个组织，新建一个项目，然后就能拿到个人token了

https://go.microsoft.com/fwlink/?LinkId=307137

默认只能一年，而且由于政策变动，目前只支持到26年12月1号，后续看情况吧

Open VSX （Cursor / VSCodium）

Cursor 扩展面板吃的是 Open VSX，步骤和 VS 平行、账号体系完全两套。

1. open-vsx.org 用 GitHub 登录
2. 注册 Eclipse Foundation 账号，GitHub Username 填成同一个 GitHub
3. 个人设置里 Log in with Eclipse，签 Open VSX Publisher Agreement（没签完一律发不出去）
4. 生成 Access Token
5. 创建 namespace（对应 package.json 的 publisher）
6. ovsx publish 或网页拖 .vsix

npx ovsx create-namespace codebinddocs -p <token>
npx ovsx publish codebind-docs-x.y.z.vsix -p <token>
# 或：npm run publish:ovsx

仓库里 publish:vsce / publish:ovsx 两边各发一遍就行。注意：Open VSX 的 namespace 可以和 VS 的 publisher 不同（我就是因为撞名被迫拆开的）。

Token

拿token比较简单，直接生成即可，后续给到CI流程进行自动化

认领 namespace

发完以后页面上很可能还有一条警告，大意是：

This version of the “CodeBind Docs” extension was published by elmagnificogi. That user account is not a verified publisher of the namespace “codebinddocs” of this extension.

意思是：扩展已经发上去了，但 codebinddocs 这个命名空间还没被官方认定归你所有。

Open VSX 和 VS Marketplace 不一样：

所以：elmagnificogi 能发版，但还不是 codebinddocs 的 verified owner。扩展能用、Cursor 也能搜到，只是详情页带 ⚠️。

消掉警告的办法：去 EclipseFdn/open-vsx.org 开一个 Issue，申请命名空间所有权，大致写：

• Open VSX / GitHub 用户名：elmagnificogi
• 要认领的 namespace：codebinddocs
• 证明你是维护者，例如仓库、VS 市场页链接

标题可以写成：Namespace Ownership Request: codebinddocs。

管理员通过后，namespace 变成 verified，你就是 owner，警告会消失（有时再发一个新版本才完全干净）。

踩坑

以为发了 VS 就能在 Cursor 搜到

社区里一堆人踩过：VS Marketplace 有货，Cursor 扩展面板搜不到。原因就是上面那条——Cursor 默认吃 Open VSX，不自动镜像 Microsoft 市场。

临时办法：本机装 .vsix（Extensions: Install from VSIX...）。长期还是得发 Open VSX。

没签 Eclipse 协议

报错大意：

You need to sign the Eclipse Foundation Open VSX Publisher Agreement…

Open VSX 是 Eclipse 基金会管的，发布者协议必须签。注意：

• 「Eclipse Contributor Agreement」和这个不是一回事
• 登录 Eclipse 时用的 GitHub，得和 open-vsx.org 登录的是同一个
• 签完回到 Profile，能看到协议相关入口才算过

namespace 太像，不让建

想建 codebind，直接被拒：

Namespace name ‘codebind’ is too similar to existing namespace(s): CodeMind.

Open VSX 有 typosquatting / 相似度检查，名字撞得太近就不给你。跟 CodeMind 差几个字母，系统觉得用户会搞混——讲道理偏严，但也没地方跟机器人扯皮。

最后改成 codebinddocs，扩展 ID 变成：codebinddocs.codebind-docs。

显示名照样可以叫 CodeBind Docs，变的是 URL / ID 那截，不是产品名。

VS 那边改不了 publisher

第一反应：那我把 VS Marketplace 也改成 codebinddocs，两边统一？

不行。 publisher.name 是扩展唯一身份：

• Publisher ID 创建后改不了
• 你自己改 package.json 再发，市场会当成另一个新扩展
• 老用户不会自动迁，下载量也不合并
• 真要迁移得找 Marketplace Support 申请 transfer，现在很少批，还一堆副作用

所以现实方案是：

• VS Marketplace：继续 codebind.codebind-docs
• Open VSX / Cursor：用 codebinddocs.codebind-docs

两边 ID 不一致，难看一点，但比下架重来强。下架还可能把名字永久占死，更亏。

删除改名

后续VS这边重新建publish，名字改成了一样的，就是删了之前的，但是上传就一直提示插件已经存在了

VS Marketplace 自大约 2025 年中起的政策是：

扩展一旦被 Remove（删除），name（ID 里第二段，例如 codebind-docs）会永久占用，原作者也不能再用。

干，所以现在要换个name上传，真的离谱了

Summary

上架扩展本身不难，难的是两个市场两套规矩，还都叫 marketplace。Publisher 核心就三件事：身份（账号 / 协议）、命名空间（撞名真的会卡死）、版本与打包（升版本、.vsix、两边各发）。

CBD 现在：

• VS：codebinddocs.codebinddocs
• Cursor：codebinddocs

Quote

https://github.com/eclipse-openvsx/openvsx/wiki/Namespace-Access

https://github.com/EclipseFdn/open-vsx.org/wiki/Guidelines-on-Namespace-Requests

2026-07-20 00:00:00

Foreword

之前学 VS Code 插件，算是半途而废。最近结合 Agent，把当时没做完的想法做完了，刚好这东西能塞进目前这套 AI 工作流里。

Agent 工作流里反复强调一件事：先文档、后代码；文档得是 Agent 能读、人能审的单一事实来源。 wolai 管产品需求没问题，但落到具体模块、具体函数时，设计上下文往往还是散的，注释里有一点、README 里有一点、脑子里有一点。于是就有了 CodeBind Docs。

为什么要做

下一代编辑器怎么吹都行，现实里无论哪种 IDE，核心还是代码；文档怎么改，都和代码是两套东西。文档不同步、散落各处，要维护就异常痛苦。

常见几种情况：

• 往源码里塞大段注释，污染代码，review 时噪音一大堆
• 文档丢到云端 wiki，和仓库版本对不上，Agent 也摸不着
• 靠人记得「这个函数的设计在某某页」，人会忘，Agent 更不会自己猜
• 与Agent共同工作，某些时候框架设计都是堆在一起的，某一个文档，但是当你看代码的时候不一定会意识到对应的文档

既然如此，为什么不把代码和文档绑紧一点？理想态当然是混在同一个文件里：上面文档（图、视频都行），下面代码，按顺序拼接，编译时再拆回去。Jupyter、Colab 某种程度上就是这条路。

但真混排对现有工程改造太狠了，语言服务器、diff、CI、同事的习惯全要跟着改。所以我先做了一版能立刻用的插件：源码零侵入，文档旁路挂在仓库 Markdown 里，打开代码时左右分栏同步看、同步改。这就是 CodeBind Docs（简称 CBD）。

CodeBind Docs

CodeBind Docs：代码文档绑定，VS Code / Cursor 都能用。

插件页面

https://marketplace.visualstudio.com/items?itemName=codebinddocs.codebinddocs

https://open-vsx.org/extension/codebinddocs/codebinddocs

仓库

https://github.com/elmagnificogi/CodeBindDocs

功能：

• 文档落在仓库的 docs/（可改路径），跟代码一起进 Git
• 绑定写在 Markdown 的 YAML 头里，不改被绑定的源码
• 支持整文件绑定，也支持某个函数/类的行范围绑定
• 打开已绑定的源文件 → 右侧自动打开对应文档；光标进到某个代码块，文档跟着切

绑定后仅仅是在文档头增加了下面的内容，一般不影响显示：

---
cbd:
  target: src/foo.ts
  kind: file          # 或 range
  startLine: 15       # range 时
  endLine: 44
  symbol: activate    # range 强烈建议填
  contentHash: abc
---

没有 cbd: 头的 Markdown 不算绑定，普通说明文档该咋放还咋放。CodeBind Docs插件仓库自己也在用：src/** 基本都挂了旁路文档，有需要看效果直接打开这个仓库即可

优势

日常用下来，比较实在的几条：

1. 分栏同步：写代码时右侧就是设计说明，少来回切窗口、少漏逻辑
2. 漂移治理：文件/目录改名尽量自动改 target；行号乱了可以按 symbol 一键重算；内容哈希变了只软提醒，不逼你，本质上是告诉你文档和代码可能不同步了
3. 人与 Agent 共用同一套上下文：改代码前先读旁路文档，代码变更尽量同一提交更新文档，这和工作流里「缺陷回流文档」是同样规范，只是粒度从需求页下沉到了模块/函数
4. 开源、独立：不依赖远程服务器，能看到代码就能看到文档，这二者永远同步

对 Agent 工作流来说，CBD 补的是 wolai 够不着的那一层：产品需求可以仍在 wolai；落到「这个文件为啥这么写」时，旁路文档 + AGENTS.md 对照表，开新会话也能直接喂进去。

五分钟上手

1. 装扩展（插件市场搜 CodeBind Docs，或装 VSIX / 源码目录），打开文件夹工作区（单文件模式扫不了绑定）
2. 命令面板跑 CBD: Initialize，创建 docs/、assets/、模板、AGENTS.md、.cursor/rules/cbd.mdc 等
3. 打开一个源文件，跑 CBD: Bind Doc to Current File，选整文件或代码块（代码块尽量填 symbol）
4. 之后切源文件就会左右分栏；左侧 Activity Bar 有 CodeBind Docs 图标，已绑定 / 待绑定一目了然

常用入口：

文档面板支持类 Typora 的即时渲染，也能切纯文本；粘贴图片会进 docs/assets/；同仓库其它文档可以用 cbd-include 只读嵌入。

竞品

思路并不新鲜。

Swimm 有点类似，但偏云端，还叠了 AI、扫描、审查一类能力：

https://swimm.io/

古人也试过「文档和代码绑在一起」：

http://www.mark-to-win.com/tutorial/176050.html

Jupyter 把代码和 Markdown 写在一起，代码还能跑：

https://zhuanlan.zhihu.com/p/478098675

Colab 更进一步，环境和运行都云上给你备好了：

https://colab.research.google.com/

CBD 和它们的差别很明确：强调本地、源码零侵入、旁路 Markdown + 分栏；不做强制云端，也不做真混排笔记本。工程仓库里的 TypeScript / 嵌入式 / 多端业务，往往更吃这套，你不需要把整个项目改成 notebook，也能让文档跟着代码走。

Summary

长远看，我仍然觉得为什么代码不可以和文档写在一起，甚至多种代码混在一起？通过文件标识区分语言，顺序唯一确定，查看时又能把各块独立挪动；页面属性决定编译类型，中间过程再生成「普通」代码文件和「普通」文档文件，相当于在编译链路里多做一次编译，让工程不再只是代码堆。CBD的下一步可能会改整个富文本文本前端，实现我的这个想法

现在的 CBD 是先把「绑得住、找得到、Agent 读得到」做到位。真混排、音视频显示、block 合并、跨 IDE、代码块重组，以后再说。

Quote

文档和代码要是老对不上，Agent 再聪明也只能猜；旁路绑住一层，至少猜的时候有据可查。

2026-07-02 00:00:00

Foreword

上一篇那套 Agent 工作流其实并不完善，它只是当下妥协出来的一套流程——文档先行、人卡在几个关口审一审、task.md 记着进度。说白了，是拿「流程纪律」硬填 Agent 接不进现有工程链路的坑。

那理想的工作流长啥样？光有纪律不够，还得往下再走一层：把调试、测试、联调都改造成 Agent 能直接上手的样子，人退到只管设计和审核。

一个够复杂的例子

先摆个够复杂的项目当靶子——能把它捋顺，剩下大部分工程场景也就差不多了：

嵌入式软件 A  基于 硬件 B
算法 C        服务于 PC 软件 D 和 PC 软件 E
PC 软件 D     基于通信协议 与嵌入式软件 A 交互
PC 软件 E     基于特定协议文件 与软件 D 交互
Web 软件 F    基于网络协议 与软件 D、E 交互
安卓端 G      基于网络协议 与软件 D 交互
iOS 端 H      基于网络协议 与软件 D 交互

这里先不考虑额外的自动化测试工程（就是那种独立于业务架构、单独起一套的测试工程）。我的想法是：测试能力最好长在每个组件自己身上，而不是另起一座测试孤岛。

flowchart LR
  B["硬件 B"] --> A["嵌入式 A"]
  A <-->|通信协议| D["PC 软件 D"]
  C["算法 C"] --> D
  C --> E["PC 软件 E"]
  D <-->|协议文件| E
  D <-->|网络协议| F["Web F"]
  D <-->|网络协议| G["安卓 G"]
  D <-->|网络协议| H["iOS H"]
  E <-->|网络协议| F

  classDef hw fill:#f8cecc,stroke:#b85450
  classDef emb fill:#dae8fc,stroke:#6c8ebf
  classDef pc fill:#d5e8d4,stroke:#82b366
  classDef net fill:#fff2cc,stroke:#d6b656
  class B hw
  class A emb
  class D,E,C pc
  class F,G,H net

这张图里，每条箭头都是 Agent 联调时要跨的边界。理想情况下，边界两头都该露出「机器能读、机器能调」的接口；可现实里呢，很多边界就只有个 GUI、一台示波器、或者一段得靠人眼看的波形——Agent 走到这儿就断了，再往前一步都迈不动。

一句话：上篇解决的是「文档和代码怎么对上」，这篇要解决的是「Agent 到底摸不摸得到这些边」。

人把路铺好，Agent 才能跑闭环

理想的 Agent 工作流，我觉得能一句话概括：

该人干的人干好——定方向、划边界、把物理和权限上的路打通；编码、联调、测试丢给 Agent；最后审核还是人来拍板。

这么一来，工程师的身份其实变了：从「自己埋头写代码」变成「设计系统 + 管 Agent」。不是说细节就不管了，而是把细节约束提前写进一个 Agent 能读、能跑、还能自己判断对错的环境里。

假如上下文真的无限

先做个假设：要是 Agent 上下文接近无限，不会「聊着聊着就忘了 S8 之前不能写代码」，那工作流就能尽量照着人类团队那套来搭——产品提需求、开发写实现、测试验结果、负责人拍板，只不过每个岗位都能换成 Agent，人只挑几步插手。

但有个坑特别容易忽略：上下文无限 ≠ Agent 就可靠了。

• 会话一长，早期定的规矩照样会被慢慢带跑偏，外部事实源（task.md、wolai 定稿）还是省不掉
• 跨会话没有「责任连续性」，得靠文档和关口一棒一棒接
• 「记得住」不等于「判断对」——复核、追溯表该做还得做

所以哪怕上下文不再是瓶颈，流程纪律和那些能被观测的边界，依旧是硬需求；区别只是你能腾出更多精力，去搞「链路打通」这件正事。

人该干啥

理想态里，人确实不用一行行去写实现了。但下面这几件事，短期内真不好甩给 Agent：

最后一条最关键：理想工作流不是干等 Agent 变强就行，而是人得主动把环境收拾成一个 Agent 能上岗干活的车间。

Agent 的壁垒

要是真打算一切围着 Agent 转，那软件之间的交互、调试、测试都得为它服务。可现在的工具链基本是给人、给业务用的，Agent 在不少环节根本插不进手。

1. 没有 CLI，也没有能下断言的输出

测试这一环，特别多是靠人眼判断的，要么软件压根没有命令行式的输入输出。这种工具 Agent 用不了，测试就又被踢回给人。上篇说过那句话：能编译通过 ≠ 能自测。

2. 图和文之间那道墙（原生 UI 尤其惨）

UI 的设计和实现之间，在非 Web 的场景下，几乎没有一门 Agent 能操作的「中间语言」——你想用代码或文字精确描述「这个控件偏了 2px」「这个动效不对劲」，太难了。Web 好歹还有 DOM 加截图兜底，桌面和移动端的原生 UI 就更吃亏。

3. 视频和图文之间，差距更大

这比静态图又高一层：时序、动画、音画同步……Agent 理解起来成本陡增。录屏加抽帧对比能缓解一点，但离「能下可靠断言」还差得远。这一层现阶段 Agent 基本进不来，只能等技术再往前走走。

4. 状态和时序这道坎

很多 bug 根本不在「某一帧画面」上，而是藏在时序、并发、中断、实时性里——协议莫名少了一帧、DMA 跟主循环抢资源、电机响应慢了 3ms。这类问题没有一张稳定的文本快照能截下来，Agent 拿不到「现场」，只能干等着人来一句「刚才好像卡了一下」。

Agent 友好

「为 Agent 改造」不能拍脑袋，我归了四条，拿来挨个对比够不够格：

可观测 — 状态能用文本或结构化数据吐出来（日志、dump、协议帧、指标）
可驱动 — 能用命令行 / API / 脚本触发，不靠鼠标点
可断言 — 结果能让程序判定对错，不只靠人眼，不凭感觉
可复现 — 同样的输入能稳定重放（硬件场景下就是能录能回放）

四条全占上，Agent 才可能在这个环节自己跑出闭环；缺一条，人就还得在那儿补位。

把 Agent 当员工

软硬件联调这块，得能模拟硬件，最好直接把真机接进流程——让 Agent 能直接调：烧录、读寄存器、发指令、读传感器，连硬件调试那条链路也接进来。

一句话：把 Agent 当个正常员工看待，人手里有啥工具，就得给它配上对应的接口。

以上述项目为例：

• 好处：不必另起一套独立测试工程架构，协议联调、硬件逻辑、软件互动可以在同一条链路上闭环验证
• 现状难点：硬件没有接入 Agent——没有「Agent 能发指令、读状态、判定硬件是否稳定」的链路打通。Agent 写完软件补丁，闭环断在真机这一侧，只能等人工测试一遍、口述结果
• 理想态：Agent 完成编码和可自动化部分的测试；人只做设计评审、安全审核、以及 Agent 够不着的物理操作授权

这其实就是上篇「测试压力全压人身上」的极端版：越靠近物理世界，改造成本越高，可一旦打通，闭环带来的收益也越大。

多Agent融合

回到 A~H 那张图，真要并行干，基本就是一个组件开一个 Agent，各跑各的会话。那它们之间怎么对齐？靠的不是谁记着谁，而是协议文档当合同——边界上的协议、报文格式、接口契约都写死在文档里，改 A 的 Agent 和改 D 的 Agent 各自照着合同来。谁想动合同，就得回到人这儿重新评审。这跟上篇团队版里「多方 Agent + 协议文档联调」是一个意思，只是这里把它当成默认姿势。

还有个容易被忽略的点：Agent 既写代码又写测试，等于自己给自己发合格证。所以人审的时候，重点不光是看代码，更得看测试本身合不合理——断言够不够狠、边界有没有漏、是不是为了让用例「变绿」把条件写松了。测试用例的设计意图这一关，还得人来守。

改造成本

为 Agent 重做调试、测试链路，是实打实要砸进去的工程量，不是改几行 Skill 就完事的：

怎么取舍：小需求、一次性脚本，犯不上全链路改造，上篇那套妥协流程就够用了。但要是个长期维护的多端 + 嵌入式产品，那越早把边界上那四条判据补齐越划算——Agent 能扛的环节越多，人就越往「架构师 + 审核员」那个位置挪。

不是所有项目都得追理想态。关键是先搞清楚断点卡在哪，再决定是花钱打通链路，还是干脆让人补位。

理想工作流

把前面这些收回到例子上，理想态大概是这么转的：

1. 人：定义各组件的职责和协议合同；把定稿沉淀到需求 / task.md；给 Agent 开通真机、网络、仓库的权限
2. Agent（可以按组件各开一条会话）：读合同 → 改 A/D/E… → 用 CLI/API 把自己这块测了 → 跨边界的就用录包 / mock / 集成脚本联调
3. 人审核：协议变更、安全相关、UI 主观体验、真机实飞——关口不过就不合并

flowchart TB
  HUMAN["人：方向 / 边界 / 权限 / 审核"]:::human
  AGENT["Agent：编码 / 自测 / 联调脚本"]:::ai
  CHAIN["Agent 友好链路<br/>CLI · 日志 · 录包 · 真机 MCP"]:::chain
  PROD["A~H 各组件"]:::prod

  HUMAN -->|定契约| PROD
  HUMAN -->|打通| CHAIN
  CHAIN --> AGENT
  AGENT -->|可观测可驱动| PROD
  AGENT -->|阻塞 / 需拍板| HUMAN

  classDef human fill:#d5e8d4,stroke:#82b366,color:#333
  classDef ai fill:#dae8fc,stroke:#6c8ebf,color:#333
  classDef chain fill:#fff2cc,stroke:#d6b656,color:#333
  classDef prod fill:#f5f5f5,stroke:#999,color:#666

说到底，上篇拼的是文档纪律，这篇拼的是环境纪律。两样叠一块，才勉强够得着「Agent 写完就能交付、人只管设计和审核」那个理想。

Summary

上篇那套妥协流程，解决的是「别让 Agent 跑偏」；这篇想再往前一步，解决「别让 Agent 卡在链路外头」。几个结论：

• 协议边界就是 Agent 的联调边界，每条边都得往「可观测、可驱动、可断言、可复现」上靠
• 四道坎：没 CLI、图文、视频、时序——越往后越难啃，嵌入式真机是最硬那块骨头
• 人的活儿变了：少写实现，多去划边界、打通物理渠道、改造环境、做审核
• 上下文再大，也替不掉外部事实源和关口
• 改造成本是真金白银，得按项目掂量——小需求用妥协流程，长期多端、嵌入式才值得砸链路下去

理想不是「Agent 啥都能干」，而是「该它闭环的地方，它真能闭上」；闭不上的，人就老老实实补位，别假装全自动。

往远了说，这事不光取决于 Agent 多聪明，更取决于整条工具链愿不愿意把「机器能用的接口」露出来——厂商给硬件、给软件配上 CLI 和 MCP，给调试器留个程序能调的口子。这一步迈出来之前，理想工作流就还只是「理想」。

Quote

人手里有啥工具，就得给 Agent 配上对应的接口——不然所谓工作流，只是换了个写代码的实习生，谈不上什么新工种。

2026-06-26 00:00:00

Foreword

前段时间在 wolai 里把一套「一个人带 Agent 做产品」的流程摸清楚了，顺手画了一张图，又写了一份更偏团队协作的 Agent 方案。下文先展开独自开发（AIO）如何把产品、开发、测试、总负责人压缩成「你 + Agent」；再讲团队版（FTM）如何拆回四个岗位。文档怎么流转、人在哪几步必须插手、以及怎么把踩过的坑固化成 Skill，两家共用。

AIO，All-in-one

FTM，Four man team

为什么要先定工作流

AI 写代码很快，快到你还没来得及想清楚需求，它已经给你造了三层抽象、两个 Design Pattern 和一个你根本没要的缓存层。没有流程约束，Agent 就像个热情过头的实习生：活干得猛，方向全靠猜，你没规范的内容往往走出了意想不到的呈现方式。

所以我现在的原则是：先文档、后代码；先评审、后构建；缺陷不只改代码，还要反向更新文档。 文档全部放在 wolai，暂时不进 Git 仓库——wolai 自带版本历史，需求和工程文档跟代码解耦，Agent 通过 MCP 读写文档，人负责拍板。

开发分为好几种

1. 从0开始的，业务是全新的，不需要理解之前的东西，很简单，全部交给AI即可
2. 从0.5开始，业务已经存在了，是对已有业务的修改或者补充，需要让AI知道当前业务到底是什么，上下文、对齐非常重要
3. 从1开始，业务完整，对某些小bug，涉及内容非常小的进行修改或者找到bug所在
4. 核心性能或者算法或者非常小众领域的类型开发，创新式的，AI很难给出满意的答案

目前Agent主要解决的是1、2、3，能完全交给Agent的基本是1和3，2需要大量的上下文和超级健全的工程框架

AIO 整体流程

流程图里绿色节点是人工，蓝色是 AI。主流程自上而下阅读（需求在顶、交付在底）；评审纠偏与缺陷回流单独成图，避免横向过宽。

主流程

flowchart TB
    A1["相关需求补充/查找"]:::ai
    H1["需求"]:::human
    H2["工程背景补充"]:::human
    A2["AI 结合工程进行需求评审"]:::ai
    A3["AI 编写技术文档"]:::ai
    H5["人工审核技术点与判断依据"]:::human
    P1["代码构建"]:::ai
    P2["测试文档 + 用例构建"]:::ai
    H7["人工测试，核验需求是否完成"]:::human
    A9["AI 复核并同步各文档"]:::ai
    H9["人工复核"]:::human
    A10["生成功能使用说明文档"]:::ai
    H10["复核文档，结束"]:::human

    A1 --> H1 --> H2 --> A2 --> A3 --> H5
    H5 --> P1 & P2
    P1 --> H7
    P2 --> H7
    H7 --> A9 --> H9 --> A10 --> H10

    NOTE["前提：相关代码仓库需可被 AI 读取"]:::note
    H2 -.-> NOTE

    classDef human fill:#d5e8d4,stroke:#82b366,color:#333
    classDef ai fill:#dae8fc,stroke:#6c8ebf,color:#333
    classDef note fill:#f5f5f5,stroke:#999,color:#666

评审纠偏与缺陷回流（主流程中未通过时进入）

flowchart TB
    subgraph R1["需求评审纠偏"]
        RA2["AI 需求评审"]:::ai
        RH3["检查理解错误"]:::human
        RH4["补充修正材料"]:::human
        RA2 --> RH3 --> RH4 --> RA2
    end

    subgraph R2["技术文档订正"]
        RH6["订正错误点"]:::human
        RA3["AI 技术文档"]:::ai
        RH6 --> RA3
    end

    subgraph R3["测试未通过"]
        RH8["向 AI 说明不符合项"]:::human
        RA7["重新修正代码"]:::ai
        RA8["回流 Skill"]:::ai
        RDOC["反向更新需求/技术/测试文档"]:::ai
        RH8 -->|实现问题| RA7
        RH8 -->|需求/设计问题| RA8 --> RDOC
    end

    classDef human fill:#d5e8d4,stroke:#82b366,color:#333
    classDef ai fill:#dae8fc,stroke:#6c8ebf,color:#333

核心链路如下：

1. 需求输入：产品需求写在需求文档中（评审后的版本）。AI 可辅助「相关需求补充/查找」，但需求正文不允许 AI 0-1 生产，只允许补充和审查——方向错了后面全白干。
2. 工程背景补充：人工补充本需求涉及的仓库、模块、历史决策、接口约束。前提：相关代码仓库都要能被 AI 读到（Cursor 打开多仓库工作区、MCP filesystem都需要准备好）。
3. AI 需求评审：Agent 结合工程上下文审需求，标出歧义、遗漏、与现有架构冲突的点。
4. 人工纠偏：检查 AI 有没有理解错；把补充材料、对开放问题的答复写回 需求文档。
5. AI 编写技术文档：输出工程设计（模块划分、接口、数据流、边界条件）。同步可起草测试文档骨架。
6. 人工审核技术文档：重点看技术选型依据、判断条件、隐含假设有没有跑偏；错了就「订正错误点」打回，对了才往下走。
7. 并行构建：代码构建与测试用例构建同时进行——代码里最好包含 CI/CD，交到测试环节时应是可运行的完整产物，而不是半截子 PR。
8. 人工测试：按测试文档走流程，核验需求是否真正完成。有问题就逐条告诉 AI 哪里不对，进入「重新修正代码」循环。
9. 缺陷回流：若发现的是需求/设计层面的问题，不能只改代码——要回流更新需求、技术、测试文档，并补上对应用例。
10. AI 复核：开发完成后，让 Agent 交叉检查需求、工程、测试、实现是否一致，文档是否互相印证，能否交付、能否合并主分支作为下一迭代基线。
11. 人工复核 + 使用文档：人做最后一眼；AI 基于定稿内容生成面向用户/运维的说明文档，再复核一遍，结束。

用一句话概括：人定方向、人审关键节点；AI 写文档、写代码、写用例、做一致性检查；文档作为单一事实来源。

下面是一个核心的 task.md 示例：补充项目信息、开发规范和任务需求，也记录 Agent 各步操作。每轮会话 Agent 都先读它再继续，整体进度同步在这里。想接续开发或并行多任务，复制一份 task 即可，互不干扰。

# 任务：abc-123

> 本文件分两部分：**【一、任务信息】** 初始化时填写、相对稳定；**【二、进度与共创记录】** 开发过程中动态更新。
> 新任务：复制本结构，重填「一」、清空「二」即为初始状态。多任务并行时每个任务一份（见 `docs/tasks/<需求ID>.md`），会话开始时指定要接续的任务。

---

# 一、任务信息（初始化头部）

## 基本信息

| 项 | 值 |
| --- | --- |
| 需求 ID | abc-123 |
| 标题 | 需求abc-123 |
| 类型 | feature |
| 模式 | solo（AIO） |
| 开发分支 | `abc` |
| 基线 | `dev` |

## 文档链接

| 文档 | 链接 |
| --- | --- |
| 需求页 | [A](https://www.wolai.com/abc) |
| 技术+测试 | [B](https://www.wolai.com/abc) |

## 关联工程项目（workspace）

- A
- B
- C

## 涉及模块

- A
- B
- C

## 架构与规范要求

- 语言/框架
- MVVM：新代码 `CommunityToolkit.Mvvm`；遗留 `PropertyChanged.Fody`
- 日志：结构化日志
- 本地化：zh-cn / en-us
- 格式/注释：
- 测试：

---

# 二、进度与共创记录

## 当前阶段

**S9 代码实现（已含 S11 复评修复；待人工确认推进 S10+）**

### 阶段清单

- [x] S0 开工登记（Wolai 需求页）
- [x] S1 需求输入
- [x] S2 工程背景（技术页 §0）
- [x] S3 需求评审
- [x] S4 人工纠偏（评审表已确认）
- [x] S5 技术+测试起草（技术页 §9–§11）
- [x] S6 审核技术
- [x] S7 测试二次补全（技术页 §11.2）
- [x] S8 评审关口（已确认进入 S9）
- [x] S9 并行构建（代码 + 33 项自动化回归 + CI）
- [ ] S10 人工测试
- [ ] S11 AI 复核（评审问题修复已先行完成）
- [ ] S12 使用说明（已写回 wolai 需求页 S12）
- [ ] S13 合并基线

## 待反馈 / 开放问题

- 暂无。

## 已确认结论（摘要）

## 变更记录

## 实现摘要 / 行动记录

FTM 团队协作版

FTM（Four Man Team）是上文 AIO 的扩展：流程骨架相同，但把人拆回四个角色，各管一摊，Agent 穿插在文档生成、代码构建和一致性复核里，人负责方向、评审和拍板。

角色分工

文档全部落在 wolai，暂不进 Git 仓库——wolai 自带版本历史，需求和工程文档与代码解耦，各角色通过 MCP 读写同一份需求页下的子文档。

团队版主流程

图例：绿色 = 人工主导，蓝色 = Agent 主导，青绿色（虚线边框） = 人机协作（结对进行）。

flowchart TB
  PM["产品经理：需求文档"]:::human
  MCP["wolai MCP"]:::note
  AG["Agent：工程 + 测试文档"]:::ai
  RV["总负责人：三文档评审"]:::human
  DEV["开发 ⇄ Agent：代码构建"]:::hybrid
  QA["测试 ⇄ Agent：用例 + 验证"]:::hybrid
  AUD["Agent：AI 复核"]:::ai
  DOC["Agent ⇄ 人工：使用/说明文档"]:::hybrid
  END["人工复核，合并基线"]:::human

  PM --> MCP
  MCP --> AG
  AG --> RV
  RV -->|通过| DEV
  RV -->|通过| QA
  DEV --> QA
  QA -->|缺陷| FIX{"缺陷类型"}
  FIX -->|实现| DEV
  FIX -->|需求/设计| PM
  QA -->|通过| AUD
  AUD --> DOC --> END

  classDef human fill:#d5e8d4,stroke:#82b366,color:#333
  classDef ai fill:#dae8fc,stroke:#6c8ebf,color:#333
  classDef hybrid fill:#c5ddd0,stroke:#5a8f7a,stroke-width:2px,stroke-dasharray:6 3,color:#333
  classDef note fill:#f5f5f5,stroke:#999,color:#666

各阶段要点：

1. 需求文档：产品写好评审后的需求，经 wolai MCP 交给代码仓库内的 Agent 读取分析，输出工程设计文档，可同时起草测试文档；工程/测试文档回写到同一需求页下。
2. 技术文档：定稿后测试同学二次补全——把技术边界、隐含状态、异常路径补进用例。不熟悉项目时，可先让 Agent 根据需求梳理「可能涉及的技术面」，再写正式工程文档。
3. 评审关口：需求、技术、测试三份文档全部评审通过后，Agent 才严格按文档开发，人做辅助；评审结论回写 wolai，未通过不得大规模写代码。
4. 代码构建：开发与 Agent 结对写代码；Code Review 人机一起做。构建含 CI/CD，交到测试时应是可运行的完整产物。
5. 测试验证：自动化用例与代码同步开发；测试工程师跑用例 + 人工走流程。缺陷按类型回流——实现问题回开发，需求/设计问题回产品/工程文档，重新走评审（可快速）后再动代码。
6. 使用文档：功能交付前，Agent 生成面向用户/运维的说明文档。
7. 人工与AI 复核：交叉检查需求、工程、测试、实现是否一致、能否互相印证、能否交付客户、能否合并主分支作为下一迭代基线。

尚待补齐的环节

团队版比 AIO 多出来的主要矛盾是文档变更通知：

• 需求变了 → 技术、测试要收到通知并同步改文档
• 技术/需求变了 → 测试要收到通知并补用例

现阶段可人工拉群喊一嗓子，也可以挂一个「监控 Agent」盯 wolai 页面版本差异，触发快速重评审。单人可以靠记忆力，团队版这里需要补足。

并行需求

多个需求若不耦合、不冲突，本地copy多个仓库，从同一基线切不同分支，各开一条 Agent 会话并行开发，互不影响。

与 AIO 独自版的差异

核心原则两家共用：先文档后代码、评审不过不构建、缺陷回流文档、合并前 AI 复核。 AIO 是 FTM 的角色折叠版，不是另一套流程。

注意事项

1. 需求不能让 AI 代写

可以让 AI 审查需求、找漏洞、补边界问题；但「要做什么」必须人说了算。否则 Agent 会悄悄帮你 scope creep，最后做出来的是「技术上很完整但没人要」的东西。

2. 评审不过，禁止进入代码阶段

评审不是形式主义。需求、技术、测试三份文档没对齐之前，不要让 Agent 大规模写代码。返工成本通常是正向开发的数倍，而且 AI 返工特别喜欢「再叠一层兼容层」，债越欠越多。

3. 代码仓库可读性是前置条件

工程背景补充那一步如果虚了，后面技术文档全是幻觉。确保相关 repo 在 Cursor 工作区内，或 MCP 能访问；单体产品就把文档和代码放同一 workspace。

4. 人机结对 Review，不是 AI 独审

代码合并前：人看业务逻辑、安全、边界；AI 看样板代码、明显 bug、风格一致性。Anthropic 自己也是这个路子。再强的模型也会漏，人也不能只肉眼看 diff。

5. 测试文档要跟着技术文档长第二遍

第一遍测试用例来自需求；技术文档定稿后，AI 应二次补全——把实现里的隐含状态、错误码、并发边界补进用例。这一步跳过，人工测试很容易漏「文档里没写但代码里做了」的行为。

6. 缺陷要分流，别只会「让 AI 再改改」

• 实现 bug → 改代码，必要时补用例
• 设计/需求问题 → 回流文档，快速重评审，再改代码
• 只改代码不更新文档，下一轮 Agent 还是会按旧文档理解，同一个坑踩两次

7. 文档变更要有通知机制

团队版可以靠人喊一嗓子；独自版容易忘。实践里要么自己养成「改需求必改技术/测试」 checklist，要么用Skill或者规则把这里约束住。

8. 敏感信息别进 prompt

密钥、内网地址、客户数据别贴给云端模型。工程文档里用占位符，本地 .cursor/rules 或环境变量说明真实配置。

9. 会话粒度：一个需求一条线

不要把五个不相关需求塞进同一个 Agent 会话。上下文越长，早期约束越容易被「遗忘」；开新会话时把 wolai 文档链接和当前分支名重新喂一遍。

从工作流到稳定 Skill

流程跑通几次之后，重复劳动会冒出来：每次都要提醒 Agent「先读 wolai」「评审不过别写代码」「缺陷要回流文档」。Skill 就是把这套口头规矩写成 Agent 能自动加载的说明书。

---
name: agent-workflow
description: >-
  Unified Agent product development workflow (AIO solo + FTM team): wolai docs,
  review gates, code/tests, defect doc sync, pre-merge audit. Use when starting
  features or bugfixes, 按工作流开发, AIO, FTM, 独自开发, 团队协作, 需求评审,
  回流文档, 合并前复核, or wolai Agent workflow.
---

# Agent 产品开发工作流

单一 Skill，内含 AIO 独自版、FTM 团队版与全部子流程。**加载本 Skill 后按「模块路由」读取对应章节执行，无需再 @ 其他 skill。**

## 核心原则

**先文档、后代码；先评审、后构建；缺陷不只改代码，还要反向更新文档。**

- **`docs/task.md` 是每个需求的核心维护文档（本地、单一事实来源）**：当前阶段、进度、待办、需要人反馈/确认的问题、已确认结论摘要、实现摘要、变更记录都实时写在这里。每轮会话**先读它、随时更新它**。
- **wolai 需求/技术/测试页是定稿沉淀**：仅当①需求发生变动，或②某些内容（评审结论、技术方案、用例、设计决策）已明确/经人确认时，由 Agent 把对应内容回写 wolai（追加或更新已有段落，**不注入固定填空模板**、不覆盖人已确认内容）。
- 代码在 workspace。task.md 与 wolai 的关系：task.md 记「正在进行/待定」，wolai 记「已定稿/共享」。

## 会话启动（每轮必做）

1. 读 `docs/task.md` → 确认当前阶段、进度、待反馈项、文档链接（**以 task.md 为状态来源**）
2. 需要已确认的需求/技术/用例细节时，再按 task.md 中链接读对应 wolai 页
3. 若无 `docs/task.md`，或无开工信息（无页面 ID / 无分支）→ 执行 [modules/create-kit.md](modules/create-kit.md)（同时建立 `docs/task.md`）
4. 确认模式：`solo`（AIO）或 `team`（FTM）
5. 声明本步阶段 ID、是否允许写业务代码

## 硬性约束

```
三文档 S8 评审未全通过 → 禁止改 src/ 等业务代码
缺陷类型 design|requirement → 先走 modules/defect-sync.md，人确认后再改代码
需求正文禁止 AI 0-1 生产，仅审查与补充
一个需求 = 一条 Agent 会话
密钥/内网/客户数据禁止进 prompt
```

## 阶段与关口

| ID | 名称 | 主导 | 写代码 |
|----|------|------|--------|
| S0 | 开工登记 | 🤖 | ❌ |
| S1 | 需求输入 | 👤 | ❌ |
| S2 | 工程背景 | 👤 | ❌ |
| S3 | AI 需求评审 | 🤖 | ❌ |
| S4 | 人工纠偏 | 👤 | ❌ |
| S5 | 技术+测试起草 | 🤖 | ❌ |
| S6 | 审核技术 | 👤 | ❌ |
| S7 | 测试补全 | 🤖 | ❌ |
| S8 | 评审关口 | 👤 | ❌ |
| S9 | 并行构建 | 🤖 | ✅ |
| S10 | 人工测试 | 👤 | ✅ 修 bug |
| S11 | AI 复核 | 🤖 | ✅ 修缺口 |
| S12 | 使用说明 | 🔀 | ❌ |
| S13 | 合并基线 | 👤 | ❌ |

**S8 关口（全满足才可 S9）**：P0 有验收标准；技术含错误码与边界；测试覆盖 P0；开放问题已决议；评审记录已回写。

**Bugfix 快速路径**：人填复现与范围 → 可选 AI 简评 → 人确认 → 直进 S9（至少 1 条测试用例）→ S10–S13 同 feature。

**阶段推进**：关键关口需人回复「确认进入 S{n}」后 Agent 才更新阶段；禁止跳阶段（bugfix 可走 B 路径）。

## 模块路由

| 场景 | 阶段 | 读取 |
|------|------|------|
| 新需求/bug 开工 | S0 / B0 | [modules/create-kit.md](modules/create-kit.md) |
| 独自开发全流程 | S0–S13 | [solo-workflow.md](solo-workflow.md) |
| 团队开发全流程 | S0–S13 | [team-workflow.md](team-workflow.md) |
| 需求评审 | S3 | [modules/requirement-review.md](modules/requirement-review.md) |
| 测试失败/需求变更 | 任意 | [modules/defect-sync.md](modules/defect-sync.md) |
| 合并前复核 | S11 | [modules/pre-merge-audit.md](modules/pre-merge-audit.md) |

**阶段 → 模块自动映射**（用户未明说时按需求页当前阶段）：

| 阶段 | 执行模块 |
|------|----------|
| S0, B0 | create-kit |
| S1–S2, S4, S6, S8, S10, S12–S13 | solo 或 team 工作流（按 MODE） |
| S3 | requirement-review |
| S5, S7, S9 | solo/team 工作流 |
| S11 | pre-merge-audit |
| 测试失败且类型未定 | 先分流 → defect-sync 或直改代码 |

## 模式选择

| 模式 | 文档 | 适用 |
|------|------|------|
| `solo` | [solo-workflow.md](solo-workflow.md) | 一人兼 PM/DEV/QA/Lead |
| `team` | [team-workflow.md](team-workflow.md) | PM、DEV、QA、Lead 分工 |

未说明时默认 `solo`；用户提 FTM/团队/四人团队 → `team`。

## 文档分工（无固定模板）

| 文档 | 人写 | Agent 写 | 人审 |
|------|------|----------|------|
| 需求 | 背景、范围、功能点、验收标准 | 评审意见（S3） | S4、S8 |
| 技术 | 工程背景（S2） | 方案、接口、数据流（S5） | S6、S8 |
| 测试 | 探索性结论（S10） | 用例起草与补全（S5/S7） | S8 |

Agent 写入 wolai 时追加章节或更新已有段落，**不覆盖**人已确认内容；变更已确认内容须走 defect-sync。

## task.md 维护约定（核心）

`docs/task.md` 由 Agent 实时维护，分为**两大部分**：

**一、任务信息（初始化头部，相对稳定）** — 开工/初始化阶段填写：

- **基本信息**：需求 ID、标题、类型、模式、开发分支、基线
- **文档链接**：wolai 需求页 / 技术页 / 测试页
- **关联工程项目**：workspace 下各仓库的用途、是否本次涉及
- **涉及模块**：仓库内子模块/目录
- **架构与规范要求**：语言/框架、DI、MVVM、日志、本地化、注释与格式规范等

**二、进度与共创记录（动态）** — 开发过程中随时更新：

- **当前阶段** + **阶段清单**（S0–S13 勾选）
- **待反馈 / 开放问题**：需要人确认或决策的事项（含选项与建议），人答复后清理或归档
- **已确认结论摘要**：指向 wolai 定稿，避免本地长篇复制
- **变更记录**：需求/技术变更条目（日期、内容、是否已回写 wolai）
- **实现摘要 / 行动记录**：本轮改了哪些文件 / 关键决策

**回写 wolai 的触发**：当待反馈项被人确认、需求发生变动、或技术/测试内容定稿时，把对应内容回写 wolai，并在变更记录中标注「已同步 wolai」。

### 新任务重置

新需求开工时复制本结构：**重填「一、任务信息」、清空「二、进度与共创记录」**（阶段清单回到全未勾、记录区清空）即为初始状态。

### 多任务并行

- 单任务：直接用 `docs/task.md`。
- 多任务并行：每个任务一份 `docs/tasks/<需求ID>.md`（如 `docs/tasks/DGCS-387.md`）。
- 会话开始时若存在多个任务文件，**由用户指定要接续的任务**（如「接续 DGCS-387」）；未指定且仅一个时默认它。

## Agent 行为协议

1. **需求正文**：👤 专属，Agent 只读 + 评审，拒绝代写
2. **技术/测试**：🤖 可起草，人审核后视为定稿
3. **写之后**：更新 `docs/task.md`（当前阶段、进度、待反馈项、实现摘要、行动记录）；内容明确或需求变动时再回写 wolai
4. **人确认**：回复「确认进入 S{n}」后才推进阶段（同步更新 task.md 阶段）
5. **子流程完成**：回到主工作流对应步骤

## 缺陷分流（全局）

```
测试未通过
├── implementation → 改代码 → 必要时补用例 → pre-merge-audit
└── design | requirement → defect-sync → 快速重评审 → 再改代码
```

## 前置条件

- [ ] wolai MCP（`user-wolai`）可用
- [ ] 相关代码仓库在 Cursor workspace 可读
- [ ] `docs/task.md` 存在（无则开工时创建）
- [ ] wolai 需求页 ID、Git 分支（开工时收集，记入 task.md）

## 文件结构

```
docs/task.md            # 每个需求的核心维护文档（状态/进度/待反馈/变更，本地事实来源）

AgentWorkflow/
├── SKILL.md
├── solo-workflow.md
├── team-workflow.md
└── modules/
    ├── create-kit.md
    ├── requirement-review.md
    ├── defect-sync.md
    └── pre-merge-audit.md
```

工程改造

目前我们的工程设计或者规范等等都是给人写的，但是很多时候Agent并不一定理解，或者说他可能没看到，这样就会导致Agent理解有偏差。

独自开发做一个大型项目里的小需求时，常常会发现缺了不少衔接——需求文档和代码实现里的关键词对不上，Agent 理解不了需求里的专有名词。这时需要先写一截技术文档，把需求和技术术语对齐，再让 Agent 通读，看还有哪些不理解，再补。

其次在技术实现细节上，很多我们默认会写的范式或模板化代码，AI 并不知道——这部分往往没有成文规范，于是 AI 写起来很「放得开」：需求能完成就行，不太在意是否符合项目整体风格，这里也需要在 task.md 或工程文档里写清楚。

再到测试：Agent 要能全流程跑起来，就必须自己能测。如果写完代码只能编译通过、没有测试手段，压力就全压到人这边——尤其实现偏差大时，光靠口头提修复意见都来不及。所以测试工具和运行环境最好都有文本化输出、命令行可驱动的输入方式，Agent 才能写完自测，交付质量才靠得住。

Summary

首次跑通一条中等需求，文档阶段可能占一半时间，会比「直接跟 Agent 说帮我做个 XXX」慢。但第二次、第三次会快很多：模板有了、Skill 上了、仓库结构 Agent 也熟了，流程就快起来了。

独自开发最缺的不是 coding 速度，是没人帮你评需求、没人帮你写用例、没人帮你喊停。工作流 + Skill 本质上是在给「未来的自己」配了几个不领工资的角色——产品审查、架构审稿、测试补位、合并前审计。人还是只有一个，但至少不用每次都靠记忆力维持纪律。

单人的好处也很明显：各仓库可以在同一工作区里打开，上下文基本不会被挡住，想读什么就能读到什么，审核也不会被自己卡住，一路畅通。

团队版最大的问题就是会被其他人阻塞，会需要等待其他人完成工作，文档之间会有互相同步的问题。

单一需求搞得定以后，就可以开始多需求并发了，毕竟有时候Agent还是要等一会的，完全可以一个大需求+一个小需求并发进行。当这种模式跑得更通了以后，可以考虑固定需求模板、工程模板、测试模板，然后将一些比较明确，不会跑偏的需求开放给Agent去直接做，人工只做最后一道收尾工作。

这是做需求的模板，bug fix也可以建立出来一套类似的模板规则，那就同样可以交给Agent去独立运行。

独自开发做了一个小需求，比较独立，和其他模块不耦合。看了一下实际 token 消耗，Cursor 大概用了 10% 的 Pro API 配额，折合约 2 美元，还能接受；一共交互了约 20 轮，耗时大概半天，等待间隙足够再开一条小需求。 一个大型项目的中等需求，消耗了30%，算起来就是6刀，交互了50次左右，主要是补充技术文档

Claude的内部plan工作流，基本和我的一致，只是我的可以灵活修改，而Claude是用harness写死的

Quote

cursor

2026-06-19 00:00:00

Foreword

没想到两个月前的一次意外，最后发展到需要“住院”的程度，治疗晚了，恢复期也被动拉长。第一次骨折，第一次正儿八经住院，给自己留个档。

骨折

发生

四月十八的小米卡丁车活动，冲得太猛了，S弯漂出去，右手直接蹭墙。墙其实是塑料壳套轮胎，按理说“看着不硬”，但身体不这么想。当时只是小拇指有点肿、右手有点擦伤，我没当回事，甚至还继续冲了决赛一节。回家后小拇指第一指节就肿起来了，还有明显疼痛感，于是冰敷了一下。刚好赶上周末，肿了2天后疼痛明显减轻，虽然还没消肿，我就又当没事人了。

一个月后，发现小拇指无法过度弯曲，正常可以弯曲到90°+，但是我只能七八十度，而且有明显牵拉的感觉，硬按或者强压下去有疼痛感，感觉不太对劲，又正好体检，一起去医院看看。

首诊

预约医院就发现闹了乌龙，预约的是总院，但是当天去的是分院，尴尬了。还好护士说可以找个大夫加号看下，于是随便选了一个骨科医生，人家直接说这个我看不了，能给你拍片，但是得找专科看。

手脚有问题得去手足科，惊了，第一次知道，骨科是看其他部位骨折的。当天能预约的只有一个二甲医院了，先选了去看看。

这个二甲医院人贼少，刚开始我还以为自己捡到医疗系统隐藏副本了。检查、见医生都不用排队，基本到了就能做。结果医生看完片子，核心意思是：已经愈合了，不用处理，不能弯就先这样，能握拳就行，要求别太高。我当场进入“礼貌但不服”模式，追问了半天，他都说去别的地方也是这结论，我只好悻悻而回。

后来跟车友分享了一下情况，建议我再去其他大医院，好一些的医生看一下。

复诊

复诊去了之前约错的总院，不得不说人确实太多了。就见医生排队等了2小时，医生看了之前的片子，说重拍一个，一共说话没五分钟。

拍片子又等了一个多小时，这医生就下班了，看片子还得等下午上班。

下午上班医院系统又有点问题，复诊号挂不上，让我直接插队。我好心让了三四个人，后面人就开始默认“你还能继续让”，我逐渐无语。

医生看完直接说要做手术，下周可以安排，直接就发住院通知了，让我等电话来办手续。

• 这会还以为住院通知只是做手术的例行办事而已，没在意

住院

周一一大早就打电话给我，让我去办住院手续，说可以安排做了。我居然醒着并成功接到电话，属实是医疗奇迹之外的另一个奇迹。

直接进外科住院部，人不多，先量血压（低压偏高，后面还有戏），然后安排床位，交代第二天几点查房、抽血、验尿等流程，后续还要找这个医生那个医生。护士还挺逗，直接告诉我主治医生是最帅的那个，看起来是个小迷妹，hhhh。然后给我戴上住院手环，很多操作都是先扫手环再扫物料，流程管理这块确实拿捏住了。

周二要求七点到，护士查房。这几天暴雨红色预警，我7:04到，依然算迟到。查房护士一句“你咋来这么晚”，我当场沉默，只好乖乖等抽血、验尿。七点这班是夜班护士，8点交完班就下班。再次量血压，低压还是偏高。分了个窗景房，视野挺好，温度像冷库，空调开得我怀疑自己住进了海鲜区。

护士表示我还要做一堆检查，以我对这手术的理解，根本不用住院，也不用做那么多检查。我和病房护士小小battle了一下，感觉她也不太清楚，最后我放弃沟通，等8点大夫查房。流程就是：护士查完，大夫再查，一层一层叠buff。

怪不得护士让我“妥协一下”，原来今天有老主任返聘来查房，要给点仪式感，让我把病号服穿起来“配合演出”。还有个大爷在睡觉，没人敢叫醒，全房间就我一个被拉出来看片子、被指点。其他人都做完了，主打一个安静恢复。医生说还要做胸透、心电图等检查，我拿“体检刚做过+手指手术为啥要胸透”据理力争，医生最后说那你把体检报告打出来就行。

“最帅的医生”今天终于见到了，确实是唯一一个抹发胶的兄弟，年轻有为。先让我继续等，等他们查完所有房间后，帅医生开始认真看我的病例和片子，确认手术方案，局麻还是全麻（这还用考虑嘛）、风险告知和术后恢复计划。

帅医生看了首诊片子，直接说这个片子拍得有问题，骨头都叠一起了，信息量太低，怪不得一开始主任医师就让我重拍。我之前还短暂怀疑过，现在看是我草率了。

现在的治疗方案是把长歪并愈合的骨痂重新处理，再打3个钢钉固定，大概六到八周后拆钉。前期可能会非常僵硬、弯不下去，需要后期复健慢慢拉回来。中间去附近医院消毒换药，别感染就行。至于心电图、胸透这些，最后都不需要了。手术大概约在明天下午或晚上，确认后白天不用去，中午过去就行。

手术

第二天办完医保事项，就回病房，刚好，告诉我下一个手术的就是我，手术需要穿病号服，里面不能穿任何自己的衣服，包括内裤袜子，但是鞋子可以穿自己的，额，这就有点点奇怪了，这鞋子贼脏的也正常穿啊？然后就发现谁把我病号裤子拿跑了，我衣服是套过一次的，他不拿，反而拿裤子，还挺爱干净的。又问护士要了一个新裤子换上，等着叫号。 今日又量了一下血压，总算正常了，但是心率不正常，心率飚到110了，平缓了一下也是100左右，他们让我别紧张，我其实一点也不紧张，我是兴奋。

轮到我之后，眼镜也不能带，直接瞎掉，护士带我去手术室。怪不得要穿鞋，这一段路还有点远，到了以后脱鞋，护士拿塑料袋帮我把鞋子提回去了，我需要躺到手术床上，也就不需要鞋子了。先在手术等待厅等着，没眼镜啥都看不清，只能看天花板，恍惚间一下回到了小时候做手术的时刻，只有苍白的手术灯和灰蓝的天花板映在眼中。听护士说我没有胸片、心电图怎么也能进手术室，对接的手术护士说只要主治医生判断不需要就行，并不是必须的。大概十分钟以后护士就推着我弯弯绕绕，再次走进电梯，大概是进了手术楼，一直推到手术室门口等待了。然后就只能听到手术护士、麻药医生的笑闹声音，还是东北口音，挺搞笑的。

又等了十多分钟以后，就推进手术室了，开始做术前准备，手术室内无影灯很多，各种连接天花板从上而下的手术设备。等主治医生来了以后就开始给手、胳膊消毒，有点烧烤上酱料的感觉，碘伏棉签涂了一遍又一遍。由于是小拇指手术，单独横了一个手术台过来放胳膊，然后医用无纺布遮挡了整个视野，看不到手术过程。先打了2针麻醉，有点疼，很快就失去小拇指的感觉了。

后续大概是主任医师做最难的，主治医生主要操作，还有一个似乎是新人，带着学习，一边讲解一边做。

术中反复拍片查看位置，调整钢丝什么的，每次都换一个人扶着我手，其他人都进屏蔽室。刚开始以为很简单，一会就能做完，实际做了一个半小时，刚好六点整做完。由于我是最后一台，护士、麻醉都等着下班呢，各种催着医生快点做，递工具、找材料都贼积极，氛围还挺好的。护士各种给主任医生打小报告，哪个主治医生特别严厉啥的，不想和他一起工作，给我听笑了。

做完以后就又躺回移动手术床，由护士推着我回病房，稍微有点社死，前面是走过来的，这会回去是躺着回去的。麻药一直没退，这会还没感觉到有多疼，交代给我一些注意事项，套了固定器以后就算结束了

理论上还要我留下观察，怕还有啥问题，我感觉还好就溜了，明早还要过来查房。

十点半麻药消失，开始疼痛，和我刚撞的时候差不多，但是那会可以冰敷，这会完全不能接触到手指，很难受。晚上睡觉也没睡好，一晚上基本都在纠结这个手放哪里能好一点，疼痛感也是一波一波的，总算熬到天亮，赶紧去医院了，接着就遇到暴雨，等我走到病房，鞋子裤子全湿了。

早上查房也没啥可说的，就给老医生看了看术中的片子，祝福两句就走了。然后做了红外烤灯2次，又拍了一次片，等到11点医院系统结算，就可以回去了，看了下住院结算8900多，个人医保账户支付了1400，医保报销了7500，真贵啊。

说是开了药，但是要等到下午才能开出来，护士说可以邮寄，我可以先走。实际中午回去还是很疼，严重影响手部操作，于是先买了一盒布洛芬缓释胶囊，吃了以后就有效果了，手部疼痛不明显了，能睡得着了。布洛芬只有12小时效果，其实晚上的时候就已经不太疼了。第二天寄过来的药也是个类似的，不过用不上了。应该手术后当晚开始疼就吃一粒的，不至于这么难受。

复健

后续是三天换一次绷带，两周后拆线，一个月后找主任医生复查，出院开的是全休1个月，挺夸张的。

换药时总算看了到伤口真面目，这么大一个钢针穿过去了，然后钢丝牵拉着里面的背后是手术缝线，家旁边的医院看了我这个表示拆线还是回原来的医院拆吧，这个他们拆不了。

怪不得我这个手指的浮肿一直消不了，一用力就感觉有啥牵拉着，手指一直麻麻的感觉，看来我还是太大意了，右手应该是完全不能用劲的，我这几天还各种用力。比较好奇，最后这个大钢针他要怎么取出来，还有钢丝都在里面了。

医保

住院上来先交5000押金，先自费。医保流程比我想象中复杂：要首诊记录，复诊记录还不行；找护士拿住院确认书，自己填受伤说明表和无第三方责任书，再加医生手术确认函，然后去医保咨询窗审批，过了再回住院收费处登记医保。整套跑完才能用上医保，流程完整得像在通关。

其实当时就治疗的话，我是有保险的，不用走医保也行，奈何拖得太久了，这会再找保险都有点无从佐证的感觉了

现在医院用DRG或者DIP来核算医保，理论上是治疗成本越可控，医院越有动力优化流程，不浪费医疗资源才合理。可现实里，像我这种手术也要占一个床位，更别说一开始那些“看着就很流程化”的心电图和胸透。抽血验尿我还能理解，至少能筛传染风险。床位虽然单价不算夸张，但资源本身是稀缺的，还是该留给更需要的人。

实际上如果真的住院，这几天也没啥事，主线任务就是一个字：等。

高血压

之前没想过我也会高血压，但是住院前测量了两次都是低压偏高，然后当天晚上我就有点头疼，于是回家以后又测量了一次，这次和早上低压一模一样，高压快140了，早上还不头疼，晚上头疼，说明这个高压对我有影响。

住院第一天又测了一次，低压依然偏高，但是比前一天低了，高压正常，不头疼。

回想一下之前头疼就不是第一次了，不知道啥时候开始，睡眠偏少以后可能第一天不头疼，连续几天少睡以后就会出现头疼一天，之前以为是没吃饭造成的，现在看应该是当时血压就高了，只是没测量过，而且每次头疼我依然正常工作、游戏、熬夜，就当没发生一样。

现在看来以后得注意饮食和锻炼身体了，这已经是一级高血压的症状了

Summary

这次确实是我太大意了。很多事看着“小问题”，拖着拖着就升级成“大工程”。早点看，真能省掉后面一长串流程和折腾。

之前觉得小拇指而已，其他指头还能正常活动，生活就没啥问题，后来发现一用力就能感觉到小拇指是需要配合工作的，看起来不起眼的肢体其实也是不可缺少的。