2026-07-30 00:00:00
最近把几个比较强的AI工具都试用了一下，对比一下
我用的最多，也是相对比较传统的代码工具，理解和使用门槛都是以程序为基准的
Cursor默认套餐的上下文大小实在是太小了才260多K，别人都1M+，大需求很容易就跑过了，还好内置了压缩上下文和长期记忆等，上下文比较大的时候会自动衔接处理，不需要特别注意。
Cursor相对没有Claude和CodeX那么激进，更偏向为已有工程和程序员协作方向服务，针对已有的工作流改动量比较小，适合循序渐进的切换到Agent工作流。
Cursor虽然想主推Agent模式，每次启动默认就是Agent对话窗口，但是这东西还是有点难用，对于现有工程还是用IDE模式更好一些。
由于Claude被5小时限制，大部分需求是Cursor做的，也只是轻度使用
满打满算也就700M token就耗尽了plan，如果全力用，估计一周就耗尽了。
Cursor发现我用尽了，还送了20刀，可以的
Claude本身不是一个像Cursor那样的独立编辑器，它的核心是agent对话式工作方式，但并不是只有纯终端聊天，主要有几种带图形界面的用法：
桌面应用（Mac/Windows），独立的Claude Code桌面应用，以会话为中心，可以并行跑多个任务，改动以diff视图呈现供你审查。
IDE插件，Claude Code有VS Code和JetBrains（IntelliJ、PyCharm等）的官方插件。你在自己熟悉的编辑器里写代码，Claude Code以侧边栏面板的形式运行，它提出的修改会以inline diff的形式直接显示在编辑器里，你可以逐个审查、接受或拒绝改动。这和Cursor的Agent/Composer模式体验很像，区别在于你用的是原生VS Code/JetBrains，而不是一个魔改的编辑器。
网页版，claude.ai/code，在云端环境跑任务，同样是对话 + diff审查的模式。
终端CLI，最原始的形态，纯命令行对话。
Cursor是“编辑器为主、AI为辅”，Claude Code是“agent为主、你负责审查”。如果你想要“自己写代码 + AI帮忙”的体验，用VS Code + Claude Code插件最合适。如果任务可以整个描述清楚丢给AI，对话式反而效率更高。
简单说，不能在Claude里直接手动编辑代码（它不是编辑器），但通过IDE插件，它可以嵌进你的编辑器，diff审查体验和Cursor的agent模式基本一致。
对比Cursor，Claude确实在输入的模态上选择是更多的，语音、图片都给出了很明显的提示，Agent可以处理，虽然现在Cursor也在抄他们的无代码化的Agent，但还是差一些。Claude的体验上感觉确实更慢一些，而且很多小问题都需要你来回答，确认，确认清楚以后给出plan，才开始下达指令，开始做。
他确实符合一般认知或者普通的方法论，但是对比其他AI工具的一句话（他就去猜你意思，直接做完给你看结果），万一做对了，那种惊喜感就没了。
Claude更倾向于和输入的用户进行对话，多次交互以后摸清用户的需求，然后总结给用户，再进行施工。对话的内容或者交互选项也基本都是围绕着Plan-AI工作流来走的。
Claude的内部plan工作流，基本和我的一致，只是我的可以灵活修改，而Claude是用harness写死的
Claude的上下文比Cursor默认要大很多，对应实际使用时跑偏的概率就小一些，由于Claude上限高，所以也看到了一个小需求，虽然中间走偏了一些，但是上下文就已经380k了，超过Cursor默认大小了
Claude Code没有Tab自动补全那种“边打字边补全”的功能，它的定位是把整个任务交给agent去完成（读代码、改多个文件、跑测试），而不是辅助你逐行手写。
Claude不太好的地方就是如果你想要看代码或者文档Claude把这部分UI隐藏得有点深，而且显示效果也比较差，给程序员用还是有点别扭，给纯小白或者是非编码类工作人员用是可以的。
Claude的plan是按照周期性恢复token用量的，这就有点问题，工作时间的token不够用，需要开更大的plan，但是闲置时间这个就闲置了，直接浪费了。这个周期性的token量还是比较小的，卡在完成一个小需求的边缘。
Claude有一点不好，安装skill或者mcp等等内容以后需要重启客户端，新对话大概率还是显示没安装，而Cursor这种安装以后都是实时更新上来的
Claude的联网搜索的意向似乎偏弱一些，有些功能或者能力网络上有最新的，但是模型偏向使用记忆内的能力，从而直接给了结论，需要给出搜索提示或者具体的链接，他才会拿最新的内容来进行工作，这个问题Cursor也有，只是Claude更明显一些
Claude Code在VSCode或者Cursor插件中，就感觉比桌面APP响应快多了，而且反馈也比较好一些，不像APP端思考超久，感觉没干活的样子。
Claude Code在干活过程中还能直接插话进去，也没有排队这种机制，不知道内部是怎么实现的，可以纠正中间跑偏的地方，这个还挺好的，最后反馈结果是两个事情同时解决
Claude Code和VSC的结合感觉总有一种不兼容的既视感，体验上能明显感觉他是额外的一块，融合的不是很好。
Claude Code也少了很多插件或者交互的支持，明显不如Cursor原生的Agent好用
Claude，一个月只用了50%多，主要还是这个时限太恶心了，Fable5还送了100刀，三个改动直接耗尽，太不经用了。
Claude主要是在两个机器上使用的，总用量差不多100M Tokens，可以看到实际和Cursor比，价格差不多，但是用量小太多了，就算全用完，估计也不到300M Tokens
自从上次被封了1000刀以后，再没弄过新的了，现在再弄一个还真麻烦。账号注册还是随便注册，但是需要短信激活验证
我的GiffGaff目前有点问题，收不到验证码，虽然号还是活着的
OpenAI目前看是安哥拉的短信是最容易过的，随便试了一个，确实可以过
目前用的接码平台，短信收到失败，可以退款，最低充值3刀，刚好够用了
https://hero-sms.com/cn/purchases/numbers
一些其他路径，利用美区苹果ID，然后使用ApplePay绕过OpenAI的支付，实际上不行，试过了，虽然可以跳过短信验证的步骤，但是无法成功支付，国内的信用卡会被拒绝。
CodeX还是有点无耻的，直接拿其他Agent工具的内容过来使用。
CodeX一上来就提示你安装插件，基本就是MCP，但是有很多软件都整合到里面了，对于小白用户来说不要太简单了
总体感觉CodeX确实反馈更快，比Cursor都快很多（基于5.6 Sol 中的模型强度），不过中性的情况下，感觉模型还是思考少一些，很容易思考不足或者写的代码是有问题的。拿来工作还是要偏向更智能一些，轻度的情况下，基本判断都有问题，就好像是个傻子，只看你给的东西，多一点点都不会思考。
比如让他检查我的文章，我给了路径，竟然告诉我没有文章，我服了。切换到极高以后，就具备自主性了，自己找文章，想尽一切办法完成目标。
CodeX的整体UI，你能感觉出来更流畅，绘制得也更精细，对比Claude，那就是个傻大黑，只抄了个皮毛。
Codex知道自己显示代码能力不够好，所以直接允许你打开对应的IDE去查看，但是总体设计逻辑上还是不鼓励你用IDE或者查看代码细节的，希望你用对话的方式进行设计。
Codex也不能像Cursor那种指定或者随手把某个内容作为修改主体给到对话框中，这个还是差点意思
Codex内置浏览器可以让你直接登录对应的网站，然后他直接用你的session来操作网站，对于小白来说不要太友好，但是这个操作行为本身也有风险。
CodeX的原型能力有点强，纯属意外，我只是提了一下我的想法，半小时内就能搭好前后端的小应用，直接就能公网发布使用。
原型风格、图片审美都还可以，结合需求，再打磨打磨，就能拿去演示了，总体下来估计一小时内就做完，很不错，有些小需求或者试错性质的东西拿这个来实验很好。
在已经做的任务中间插入一个提示或者改动，流程也很丝滑，也有对应的反馈，对比Claude，插入内容完全没反馈。
不过用量还是有点捉急，一个原型从site转向自建部署，就耗尽了，我一直开的是5.6 Sol 最智能的级别。同等情况下Cursor用量大概消耗了33%，但是Cursor不能恢复。
CodeX是基于windows商店的，安装贼慢，然后内置的浏览器还容易崩溃、出问题以后必须重装才行，这么明显的bug竟然没修有点不可思议。
Cursor和Claude基本是一起测试使用的，大概是3周左右，消耗了10亿Tokens。
CodeX是最后用的，刚好是取消了5小时限制，只有周限制了，感觉也有点不耐用，但是每周能恢复，这一点很好
CodeX交互业内领先确实没问题，其他人只够追在后面吃尘。
cursor、claude、CodeX
2026-07-21 00:00:00
CodeBind Docs 写完、VS Marketplace也挂上去了，本以为Cursor那边搜一下就能装。结果发现：Cursor扩展市场不跟Microsoft那套走，得另发一份到Open VSX。下面把VS Code怎么发、Open VSX怎么发、以及这趟踩的坑一起记下来，免得下次又忘。
Cursor和VS Code的插件市场原本是一套，但是后来微软收紧策略，导致分开了，变成了2个市场。
Cursor里有两套完全不同的“市场”，名字都带marketplace
| 名字 | 实际装啥 | 怎么上架 |
|---|---|---|
| Extensions（扩展面板） | VS Code 那类插件，CBD 就是这个 | 发到 Open VSX |
| Plugins（Customize / cursor.com/marketplace） | rules、skills、MCP、hooks | 另搞一套 .cursor-plugin/，走人工审核 |
CBD是正经VS Code扩展，跟Cursor Plugin那套无关。想让人在Cursor里 Ctrl+Shift+X 搜到，只发Microsoft Marketplace不够，必须再发Open VSX。
官方也写明了：Cursor第三方扩展走Open VSX，中间再套一层他们自己的安全扫描代理。
官方文档：Publishing Extensions。下面按我实际走过的顺序记。
本地 npm run compile 过，扩展开发宿主里跑得起来，上架前最好再过一遍测试。打包工具用官方的 @vscode/vsce（老包名 vsce 别再用）。
package.json 至少这些要齐，缺了会拒：
| 字段 | 说明 |
|---|---|
name |
扩展名，小写、短横线，进 ID 的那截 |
publisher |
发布者 ID，跟市场里建的一模一样 |
version |
semver，每次改内容再发必须升 |
engines.vscode |
最低 VS Code 版本 |
displayName / description
|
市场展示用 |
icon |
建议 128×128 PNG |
repository |
仓库地址，市场页会挂链接 |
另外README、CHANGELOG、LICENSE建议都有，市场页长什么样，基本看README。CBD还补了 keywords、categories、galleryBanner，好看一点而已。
扩展完整ID = publisher.name，例如 codebind.codebind-docs。这个ID以后基本改不了，起名字时想清楚。
Marketplace 认证挂在 Azure DevOps 上，所以要先搞 Personal Access Token：
- 打开 Azure DevOps，用微软账号登录（跟后面建 Publisher 用同一个）
- 用户设置 → Personal access tokens → New Token
- Organizations 选 All accessible organizations（选成某个具体 org 很容易发不出去）
- Scopes 勾 Marketplace → Manage
- 创建后立刻复制，关掉就再也看不见了
这完全是Agent的说法，实际个人作者根本不需要，直接走下步即可
codebind）ID别跟显示名搞混：ID是机器认的，Name是给人看的。
命令行一把梭：
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...。
version，同一版本号覆盖不了unpublish 和“彻底删除”不是一回事，删除后名字可能被永久占用，慎用.vscodeignore 写清楚，别把 node_modules、测试产物、开发脚本打进包，反过来媒体、out/、README别误忽略CBD这边VS市场页：
https://marketplace.visualstudio.com/items?itemName=codebind.codebind-docs
拿token，需要先新建一个组织，新建一个项目，然后就能拿到个人token了
https://go.microsoft.com/fwlink/?LinkId=307137
默认只能一年，而且由于政策变动，目前只支持到26年12月1号，后续看情况吧
Cursor扩展面板吃的是Open VSX，步骤和VS平行、账号体系完全两套。
package.json 的 publisher）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比较简单，直接生成即可，后续给到CI流程进行自动化
发完以后页面上很可能还有一条警告，大意是：
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不一样：
| VS Marketplace | Open VSX | |
|---|---|---|
| 建 publisher / namespace | 你就是所有者 | 你只是 contributor，能发版 |
| 验证勾 | 建好就有 | 还要再 claim ownership 一次 |
所以：elmagnificogi 能发版，但还不是 codebinddocs 的verified owner。扩展能用、Cursor也能搜到，只是详情页带 ⚠️。
消掉警告的办法：去 EclipseFdn/open-vsx.org 开一个Issue，申请命名空间所有权，大致写：
elmagnificogi
codebinddocs
标题可以写成：Namespace Ownership Request: codebinddocs。
管理员通过后，namespace变成verified，你就是owner，警告会消失（有时再发一个新版本才完全干净）。
实际我已经获得授权了，但是依然未认证，这个需要github上继续联系对方，他应该只是设置了publisher，但是没把你设置为owner，导致这个命名空间一直没有被切换过来。
社区里一堆人踩过：VS Marketplace有货，Cursor扩展面板搜不到。原因就是上面那条，Cursor默认吃Open VSX，不自动镜像Microsoft市场。
临时办法：本机装 .vsix（Extensions: Install from VSIX...）。长期还是得发Open VSX。
报错大意：
You need to sign the Eclipse Foundation Open VSX Publisher Agreement…
Open VSX是Eclipse基金会管的，发布者协议必须签。注意：
想建 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 Marketplace也改成 codebinddocs，两边统一？
不行。publisher.name 是扩展唯一身份：
package.json 再发，市场会当成另一个新扩展所以现实方案是：
codebind.codebind-docs
codebinddocs.codebind-docs
两边ID不一致，难看一点，但比下架重来强。下架还可能把名字永久占死，更亏。
后续VS这边重新建publish，名字改成了一样的，就是删了之前的，但是上传就一直提示插件已经存在了
VS Marketplace自大约2025年中起的政策是：
扩展一旦被 Remove（删除），
name（ID 里第二段，例如codebind-docs）会永久占用，原作者也不能再用。
干，所以现在要换个name上传，真的离谱了
上架扩展本身不难，难的是两个市场两套规矩，还都叫marketplace。Publisher核心就三件事：身份（账号 / 协议）、命名空间（撞名真的会卡死）、版本与打包（升版本、.vsix、两边各发）。
CBD现在：
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
之前学VS Code插件，算是半途而废。最近结合Agent，把当时没做完的想法做完了，刚好这东西能塞进目前这套AI工作流里。
Agent工作流里反复强调一件事：先文档、后代码，文档得是Agent能读、人能审的单一事实来源。wolai管产品需求没问题，但落到具体模块、具体函数时，设计上下文往往还是散的，注释里有一点、README里有一点、脑子里有一点。于是就有了CodeBind Docs。
下一代编辑器怎么吹都行，现实里无论哪种IDE，核心还是代码，文档怎么改，都和代码是两套东西。文档不同步、散落各处，要维护就异常痛苦。
常见几种情况：
既然如此，为什么不把代码和文档绑紧一点？理想态当然是混在同一个文件里：上面文档（图、视频都行），下面代码，按顺序拼接，编译时再拆回去。Jupyter、Colab某种程度上就是这条路。
但真混排对现有工程改造太狠了，语言服务器、diff、CI、同事的习惯全要跟着改。所以我先做了一版能立刻用的插件：源码零侵入，文档旁路挂在仓库Markdown里，打开代码时左右分栏同步看、同步改。这就是CodeBind Docs（简称CBD）。
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绑定后仅仅是在文档头增加了下面的内容，一般不影响显示：
---
cbd:
target: src/foo.ts
kind: file # 或 range
startLine: 15 # range 时
endLine: 44
symbol: activate # range 强烈建议填
contentHash: abc
---
没有 cbd: 头的Markdown不算绑定，普通说明文档该咋放还咋放。CodeBind Docs插件仓库自己也在用：src/** 基本都挂了旁路文档，有需要看效果直接打开这个仓库即可
| 痛点 | CBD 怎么搞 |
|---|---|
| 文档散、和代码对不上 | 绑定写在文档头，跟文件 / 行范围走 |
| 注释污染源码 | 不改源码，旁路 Markdown |
| 云端文档难版本控制 | 纯本地、可 Git，无强制云端 |
| Agent 不知道读哪 | Initialize 生成 AGENTS.md / Cursor rules，文档就在仓库里 |
日常用下来，比较实在的几条：
target，行号乱了可以按symbol一键重算，内容哈希变了只软提醒，不逼你，本质上是告诉你文档和代码可能不同步了对Agent工作流来说，CBD补的是wolai够不着的那一层：产品需求可以仍在wolai，落到“这个文件为啥这么写”时，旁路文档 + AGENTS.md 对照表，开新会话也能直接喂进去。
CBD: Initialize，创建 docs/、assets/、模板、AGENTS.md、.cursor/rules/cbd.mdc 等CBD: Bind Doc to Current File，选整文件或代码块（代码块尽量填symbol）常用入口：
| 入口 | 作用 |
|---|---|
CBD: Open Docs Index |
文档主页（树、覆盖率、漂移提醒） |
| 源码顶部 CodeLens / 状态栏 | 打开旁路文档 |
| 侧栏 已绑定 / 待绑定 | 浏览与补绑 |
文档面板支持类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，也能让文档跟着代码走。
长远看，我仍然觉得为什么代码不可以和文档写在一起，甚至多种代码混在一起？通过文件标识区分语言，顺序唯一确定，查看时又能把各块独立挪动，页面属性决定编译类型，中间过程再生成“普通”代码文件和“普通”文档文件，相当于在编译链路里多做一次编译，让工程不再只是代码堆。CBD的下一步可能会改整个富文本文本前端，实现我的这个想法
现在的CBD是先把“绑得住、找得到、Agent读得到”做到位。真混排、音视频显示、block合并、跨IDE、代码块重组，以后再说。
文档和代码要是老对不上，Agent 再聪明也只能猜；旁路绑住一层，至少猜的时候有据可查。
2026-07-02 00:00:00
上一篇那套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 能用的接口 | 现实里常见的断点 |
|---|---|---|
| A ↔ B | 仿真器 / 真机 MCP、寄存器 dump、固件烧录 CLI | 只有 JTAG 调试器，外加人眼看灯 |
| D ↔ A | 协议帧日志、回放脚本、mock 设备 | 只有串口助手，肉眼对十六进制 |
| D ↔ E | 协议文件 + 结构化 diff | 二进制专有格式，连 schema 都没有 |
| D ↔ F/G/H | HTTP/gRPC 契约 + 集成测试 API | 一堆 UI 点击流，没有 headless 入口 |
| 算法 C | 固定输入输出向量、基准测试 CLI | 只有 MATLAB 图，没法量化断言 |
一句话：上篇解决的是“文档和代码怎么对上”，这篇要解决的是“Agent到底摸不摸得到这些边”。
理想的Agent工作流，我觉得能一句话概括：
该人干的人干好，定方向、划边界、把物理和权限上的路打通，编码、联调、测试丢给Agent，最后审核还是人来拍板。
这么一来，工程师的身份其实变了：从“自己埋头写代码”变成“设计系统 + 管Agent”。不是说细节就不管了，而是把细节约束提前写进一个Agent能读、能跑、还能自己判断对错的环境里。
先做个假设：要是Agent上下文接近无限，不会“聊着聊着就忘了S8之前不能写代码”，那工作流就能尽量照着人类团队那套来搭，产品提需求、开发写实现、测试验结果、负责人拍板，只不过每个岗位都能换成Agent，人只挑几步插手。
但有个坑特别容易忽略：上下文无限也不等于Agent就可靠了。
task.md、wolai定稿）还是省不掉所以哪怕上下文不再是瓶颈，流程纪律和那些能被观测的边界，依旧是硬需求，区别只是你能腾出更多精力，去搞“链路打通”这件正事。
理想态里，人确实不用一行行去写实现了。但下面这几件事，短期内真不好甩给Agent：
| 人留着的活 | 为啥甩不掉 |
|---|---|
| 定方向、划范围 | 「要做啥」得人说了算，不然 Agent 分分钟给你 scope creep |
| 划协议和模块边界 | A~H 之间谁跟谁说话、合同是啥，这得架构师定 |
| 打通物理世界 | 真机、夹具、烧录器、各种权限——Agent 没有手，够不着 |
| 审核拍板 | 安全、业务意图、能不能交给客户，这些 AI 不背锅 |
| 把工程改造成 Agent 友好 | 加 CLI、加结构化日志、加可回放测试——这是落到人头上的新「搬砖」 |
最后一条最关键：理想工作流不是干等Agent变强就行，而是人得主动把环境收拾成一个Agent能上岗干活的车间。
要是真打算一切围着Agent转，那软件之间的交互、调试、测试都得为它服务。可现在的工具链基本是给人、给业务用的，Agent在不少环节根本插不进手。
测试这一环，特别多是靠人眼判断的，要么软件压根没有命令行式的输入输出。这种工具Agent用不了，测试就又被踢回给人。上篇说过那句话：能编译通过不等于能自测。
UI的设计和实现之间，在非Web的场景下，几乎没有一门Agent能操作的“中间语言”，你想用代码或文字精确描述“这个控件偏了2px”“这个动效不对劲”，太难了。Web好歹还有DOM加截图兜底，桌面和移动端的原生UI就更吃亏。
这比静态图又高一层：时序、动画、音画同步……Agent理解起来成本陡增。录屏加抽帧对比能缓解一点，但离“能下可靠断言”还差得远。这一层现阶段Agent基本进不来，只能等技术再往前走走。
很多bug根本不在“某一帧画面”上，而是藏在时序、并发、中断、实时性里，协议莫名少了一帧、DMA跟主循环抢资源、电机响应慢了3ms。这类问题没有一张稳定的文本快照能截下来，Agent拿不到“现场”，只能干等着人来一句“刚才好像卡了一下”。
“为Agent改造”不能拍脑袋，我归了四条，拿来挨个对比够不够格：
可观测 — 状态能用文本或结构化数据吐出来（日志、dump、协议帧、指标）
可驱动 — 能用命令行 / API / 脚本触发，不靠鼠标点
可断言 — 结果能让程序判定对错，不只靠人眼，不凭感觉
可复现 — 同样的输入能稳定重放（硬件场景下就是能录能回放）
四条全占上，Agent才可能在这个环节自己跑出闭环，缺一条，人就还得在那儿补位。
软硬件联调这块，得能模拟硬件，最好直接把真机接进流程，让Agent能直接调：烧录、读寄存器、发指令、读传感器，连硬件调试那条链路也接进来。
一句话：把Agent当个正常员工看待，人手里有啥工具，就得给它配上对应的接口。
以上述项目为例：
这其实就是上篇“测试压力全压人身上”的极端版：越靠近物理世界，改造成本越高，可一旦打通，闭环带来的收益也越大。
回到A~H那张图，真要并行干，基本就是一个组件开一个Agent，各跑各的会话。那它们之间怎么对齐？靠的不是谁记着谁，而是协议文档当合同，边界上的协议、报文格式、接口契约都写死在文档里，改A的Agent和改D的Agent各自照着合同来。谁想动合同，就得回到人这儿重新评审。这跟上篇团队版里“多方Agent + 协议文档联调”是一个意思，只是这里把它当成默认姿势。
还有个容易被忽略的点：Agent既写代码又写测试，等于自己给自己发合格证。所以人审的时候，重点不光是看代码，更得看测试本身合不合理，断言够不够狠、边界有没有漏、是不是为了让用例“变绿”把条件写松了。测试用例的设计意图这一关，还得人来守。
为Agent重做调试、测试链路，是实打实要砸进去的工程量，不是改几行Skill就完事的：
| 要砸的地方 | 举个例子 | 短期啥感受 |
|---|---|---|
| 协议可观测 | D↔A 通信录包 + 文本回放 | 开发节奏变慢 |
| 原生 UI 可测 | G/H 加 headless 或截图 diff 管线 | 得动客户端架构 |
| 硬件在环 | 真机 MCP、仿真器、安全互锁 | 要硬件团队配合 |
| 规范成文 | MVVM、日志、目录约定写进 task.md
|
文档变厚 |
怎么取舍：小需求、一次性脚本，犯不上全链路改造，上篇那套妥协流程就够用了。但要是个长期维护的多端 + 嵌入式产品，那越早把边界上那四条判据补齐越划算，Agent能扛的环节越多，人就越往“架构师 + 审核员”那个位置挪。
不是所有项目都得追理想态。关键是先搞清楚断点卡在哪，再决定是花钱打通链路，还是干脆让人补位。
把前面这些收回到例子上，理想态大概是这么转的：
task.md，给Agent开通真机、网络、仓库的权限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写完就能交付、人只管设计和审核”那个理想。
上篇那套妥协流程，解决的是“别让Agent跑偏”，这篇想再往前一步，解决“别让Agent卡在链路外头”。几个结论：
理想不是“Agent啥都能干”，而是“该它闭环的地方，它真能闭上”，闭不上的，人就老老实实补位，别假装全自动。
往远了说，这事不光取决于Agent多聪明，更取决于整条工具链愿不愿意把“机器能用的接口”露出来，厂商给硬件、给软件配上CLI和MCP，给调试器留个程序能调的口子。这一步迈出来之前，理想工作流就还只是“理想”。
人手里有啥工具，就得给 Agent 配上对应的接口——不然所谓工作流，只是换了个写代码的实习生，谈不上什么新工种。
https://mp.weixin.qq.com/s/MnEEHNCYnHGLK1g24KMlUA
https://mp.weixin.qq.com/s/N1Mki1F3VX_PDwr_1jtRWA
2026-06-26 00:00:00
前段时间在wolai里把一套“一个人带Agent做产品”的流程摸清楚了，顺手画了一张图，又写了一份更偏团队协作的Agent方案。下文先展开独自开发（AIO）如何把产品、开发、测试、总负责人压缩成“你 + Agent”，再讲团队版（FTM）如何拆回四个岗位。文档怎么流转、人在哪几步必须插手、以及怎么把踩过的坑固化成Skill，两家共用。
AIO，All-in-one
FTM，Four man team
AI写代码很快，快到你还没来得及想清楚需求，它已经给你造了三层抽象、两个Design Pattern和一个你根本没要的缓存层。没有流程约束，Agent就像个热情过头的实习生：活干得猛，方向全靠猜，你没规范的内容往往走出了意想不到的呈现方式。
所以我现在的原则是：先文档、后代码，先评审、后构建，缺陷不只改代码，还要反向更新文档。文档全部放在wolai，暂时不进Git仓库，wolai自带版本历史，需求和工程文档跟代码解耦，Agent通过MCP读写文档，人负责拍板。
开发分为好几种
目前Agent主要解决的是1、2、3，能完全交给Agent的基本是1和3，2需要大量的上下文和超级健全的工程框架
流程图里绿色节点是人工，蓝色是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
核心链路如下：
用一句话概括：人定方向、人审关键节点，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（Four Man Team）是上文AIO的扩展：流程骨架相同，但把人拆回四个角色，各管一摊，Agent穿插在文档生成、代码构建和一致性复核里，人负责方向、评审和拍板。
角色分工
| 角色 | 主要职责 |
|---|---|
| 产品经理 | 维护需求文档与总体进度看板；需求由人写，AI 只审不改 |
| 软件开发工程师 | 补充工程背景；与 Agent 结对完成代码构建和 Code Review |
| 自动化测试工程师 | 审测试文档、补探索性用例；跑自动化 + 人工流程验证 |
| 总负责人 | 需求/技术/测试三份文档最终评审拍板；决定是否进入开发与合并 |
文档全部落在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
各阶段要点：
尚待补齐的环节
团队版比AIO多出来的主要矛盾是文档变更通知：
现阶段可人工拉群喊一嗓子，也可以挂一个“监控Agent”盯wolai页面版本差异，触发快速重评审。单人可以靠记忆力，团队版这里需要补足。
并行需求
多个需求若不耦合、不冲突，本地copy多个仓库，从同一基线切不同分支，各开一条Agent会话并行开发，互不影响。
与AIO独自版的差异
| 维度 | FTM 团队版 | AIO 独自版 |
|---|---|---|
| 看板与进度 | 产品维护 | 自己维护 wolai 需求页 |
| 评审拍板 | 总负责人终审 | 「未来的自己」隔几小时/隔天再审 |
| 测试用例 | 测试工程师主导，Agent 起草 | Agent 起草 + 自己补探索性测试 |
| 跨端协作 | 多方 Agent + 协议文档联调 | 多仓库各开 Agent，协议为边界 |
| 变更通知 | 需显式机制（人或监控 Agent） | 容易遗漏，靠 checklist 自律 |
核心原则两家共用：先文档后代码、评审不过不构建、缺陷回流文档、合并前AI复核。AIO是FTM的角色折叠版，不是另一套流程。
可以让AI审查需求、找漏洞、补边界问题，但“要做什么”必须人说了算。否则Agent会悄悄帮你scope creep，最后做出来的是“技术上很完整但没人要”的东西。
评审不是形式主义。需求、技术、测试三份文档没对齐之前，不要让Agent大规模写代码。返工成本通常是正向开发的数倍，而且AI返工特别喜欢“再叠一层兼容层”，债越欠越多。
工程背景补充那一步如果虚了，后面技术文档全是幻觉。确保相关repo在Cursor工作区内，或MCP能访问，单体产品就把文档和代码放同一workspace。
代码合并前：人看业务逻辑、安全、边界，AI看样板代码、明显bug、风格一致性。Anthropic自己也是这个路子。再强的模型也会漏，人也不能只肉眼看diff。
第一遍测试用例来自需求，技术文档定稿后，AI应二次补全，把实现里的隐含状态、错误码、并发边界补进用例。这一步跳过，人工测试很容易漏“文档里没写但代码里做了”的行为。
团队版可以靠人喊一嗓子，独自版容易忘。实践里要么自己养成“改需求必改技术/测试” checklist，要么用Skill或者规则把这里约束住。
密钥、内网地址、客户数据别贴给云端模型。工程文档里用占位符，本地 .cursor/rules 或环境变量说明真实配置。
不要把五个不相关需求塞进同一个Agent会话。上下文越长，早期约束越容易被“遗忘”，开新会话时把wolai文档链接和当前分支名重新喂一遍。
流程跑通几次之后，重复劳动会冒出来：每次都要提醒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才能写完自测，交付质量才靠得住。
首次跑通一条中等需求，文档阶段可能占一半时间，会比“直接跟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写死的
cursor
https://mp.weixin.qq.com/s/MnEEHNCYnHGLK1g24KMlUA
https://mp.weixin.qq.com/s/N1Mki1F3VX_PDwr_1jtRWA