1. 先搞清楚一个人九个月20万行到底意味着什么先把数字摊开看。九个月按每月22个工作日算大概198个工作日。20万行代码平摊下来每天要产出1000行左右的有效代码。这个量级如果靠手敲别说质量光是打字速度都撑不住。所以这个项目从一开始就注定不是写出来的而是编排出来的——人负责决策、拆解、验收机器负责生成、补全、重构。每个月烧掉40亿 token这个数字更值得琢磨。40亿token是什么概念按主流大模型的中文处理能力1个token大约对应0.6到0.8个汉字40亿token差不多是25到30亿汉字的吞吐量。一个中型技术团队一年的文档产出可能都到不了这个量级。这说明整个开发过程里模型不是偶尔被调用一下而是深度嵌入了编码、测试、文档、重构的每一个环节。关键词里出现了Harness、Agent、Claude Code、Obsidian、Markdown这几个词基本能勾勒出这个项目的轮廓这是一款基于Harness架构的应用用Agent驱动开发流程借助Claude Code这类编码代理工具完成大量代码生成同时用Obsidian管理知识库和项目文档Markdown贯穿整个内容层。所谓Harness架构你可以把它理解成马具——马本身有力量但需要一套缰绳、鞍具、轭具把它约束到正确的方向上。放到软件里Harness就是包裹在模型外面的一层控制框架它负责给模型提供上下文、约束输出格式、管理工具调用、处理错误重试、维护状态。模型是那匹马Harness是让这匹马能拉车而不是乱跑的那套装备。这个项目真正有价值的地方不是20万行这个数字本身而是它验证了一件事单个人借助合理的Harness设计和Agent编排可以撑起过去需要一个小团队才能完成的工程量。下面我把这套东西拆开讲包括架构怎么设计、token怎么花、坑在哪里、哪些环节必须人工介入。2. Harness架构的核心把模型当执行器而不是大脑2.1 为什么不能直接让模型自由发挥很多人第一次用编码Agent做法是打开对话框输入帮我实现一个用户登录功能然后等着模型吐代码。前几次会觉得惊艳用久了就会发现三个致命问题。第一是上下文漂移。模型在多轮对话里会逐渐丢失早期约定比如你一开始说所有接口返回统一用Result包装聊到第30轮它可能就忘了开始直接返回裸对象。第二是格式不稳定同样的需求这次给你返回一个完整文件下次给你返回一个diff片段再下次给你一段伪代码。第三是无法复用每次都要重新描述背景前面踩过的坑后面还会再踩。Harness架构要解决的就是这三个问题。它的思路是不让模型直接面对需求而是让模型面对结构化的任务单元。每个任务单元自带上下文、自带约束、自带验收标准。模型只负责在这个小格子里把活干好不需要它记住全局。2.2 一个可落地的Harness分层我在实际项目里把Harness分成四层从上到下依次是编排层决定下一步做什么。它维护一个任务队列根据当前项目状态决定是继续写代码、跑测试、还是修bug。这一层可以用简单的状态机实现也可以用另一个模型来做决策。上下文层负责给模型看什么。它从代码库、文档库、历史对话里检索相关内容组装成提示词。这一层是token消耗的大头也是决定输出质量的关键。执行层真正调用模型的地方。它负责发请求、处理流式返回、解析工具调用、捕获异常。验证层拿到模型输出后自动跑lint、跑类型检查、跑单元测试不通过就打回重来。这四层里编排层和验证层是人工设计密度最高的地方上下文层是token烧得最狠的地方执行层反而是最标准化的。2.3 任务单元的粒度控制粒度太粗模型容易跑偏粒度太细编排开销会吃掉大部分收益。我摸索出来的经验是一个任务单元对应一个可独立验证的代码变更通常不超过200行diff。比如实现用户登录太粗拆成定义登录请求的DTO、实现密码哈希校验函数、编写登录接口的controller、为登录接口写单元测试就合适。每个单元都能单独跑测试验证失败了也不会污染其他部分。这里有个反直觉的点任务拆得越细token总消耗反而可能越高因为每个任务都要重新组装上下文。但如果拆得不够细返工率会飙升返工一次的token消耗远超多拆几个任务。所以要在上下文重复开销和返工开销之间找平衡点。我的做法是让上下文层做缓存相同的基础上下文比如项目规范、目录结构只组装一次后续任务复用。3. 每月40亿token是怎么烧掉的以及怎么烧得更值3.1 token消耗的四个主要出口把40亿token拆开看大致分布是这样的消耗出口占比估算说明上下文组装45%每次任务都要把相关代码、文档、规范塞进提示词代码生成25%模型实际输出的代码和解释测试与修复循环20%测试失败后重新生成、重新验证文档与知识整理10%生成Markdown文档、更新Obsidian笔记上下文组装占了大头这符合直觉。一个中等规模的项目光是把相关模块的代码读进来一次就是几万token。如果每个任务都全量读取消耗会失控。3.2 上下文压缩的三个手段手段一分层检索而不是全量加载。不要把所有代码都塞给模型而是先用关键词或向量检索找出与当前任务最相关的文件只加载这些。我通常控制在单次任务上下文不超过30个文件、总量不超过8万token。手段二用摘要替代原文。对于不直接修改但需要了解的模块用之前生成的模块摘要代替完整代码。摘要可以提前用模型批量生成一次生成长期复用。一个2000行的模块摘要可能只有300字压缩比接近20倍。手段三规范外置。项目编码规范、命名约定、目录结构这些固定内容不要每次重复塞进提示词而是写成一个独立的规范文件在系统提示里引用一次即可。Claude Code这类工具支持项目级的配置文件把规范写进去后续所有调用自动带上。3.3 什么时候该用便宜模型什么时候必须上贵模型40亿token如果全用最贵的模型成本会非常难看。实际项目里必须做模型分级便宜模型用于代码格式化、简单重构、文档摘要生成、日志分析。这些任务对推理能力要求低用便宜模型完全够。中等模型用于常规功能实现、单元测试编写、bug初步定位。贵模型用于架构决策、复杂bug根因分析、跨模块重构方案设计。这类任务调用频率低但每次都很关键。我自己的比例大概是便宜模型占调用次数的60%中等模型30%贵模型10%。这样整体成本能压下来一大截而关键决策的质量不受影响。提示模型分级不是固定的随着项目推进要动态调整。项目早期架构决策多贵模型占比高项目后期主要是维护和补测试便宜模型占比会上升。4. Agent编排让机器自己决定下一步干什么4.1 从人指挥Agent到Agent指挥Agent最初级的用法是人盯着屏幕手动输入指令。这种方式在项目初期没问题但到了中后期任务数量爆炸人根本盯不过来。这时候需要引入编排Agent——它不直接写代码而是负责拆解任务、分配任务、检查结果。编排Agent的核心逻辑是一个循环读取当前项目状态哪些测试挂了、哪些TODO没完成、哪些模块覆盖率低→ 生成任务列表 → 按优先级排序 → 逐个派发给执行Agent → 收集结果 → 更新状态 → 进入下一轮。这个循环听起来简单但实际跑起来有几个坑。4.2 编排Agent最容易犯的三个错误错误一任务重复派发。编排Agent看到登录接口测试覆盖率低派发了一个补测试的任务。执行Agent干到一半编排Agent下一轮扫描又看到同样的问题又派发一次。结果两个Agent同时改同一个文件冲突了。解决办法是给每个任务加状态标记派发前先检查是否已有进行中的任务。错误二优先级判断失准。编排Agent倾向于先处理容易完成的任务因为这样能快速看到进度。但实际项目里应该优先处理阻塞其他任务的项。比如数据库schema没定后面所有涉及数据读写的任务都做不了。这个优先级逻辑必须人工写进编排规则里不能指望模型自己悟出来。错误三无限重试。一个任务失败了编排Agent重试再失败再重试token就这么烧没了。必须设置重试上限比如连续失败3次就标记为需要人工介入跳过它继续做别的。4.3 人工介入的四个关键节点完全无人值守是不现实的至少在这四个节点必须有人看一眼架构变更任何涉及模块拆分、接口重新定义、数据模型调整的变更必须人工确认。模型很容易做出局部合理但全局冲突的决策。依赖引入模型可能会为了图方便引入新的第三方库。每引入一个依赖都要人工评估否则项目后期会变成依赖地狱。安全相关代码涉及认证、授权、加密、输入校验的代码必须人工review。模型在这方面的输出不能盲信。测试通过但逻辑可疑有时候测试全绿但实现方式明显有问题比如把断言改宽松了让测试通过。这种要人工抽查。5. Claude Code与Obsidian在流程里的实际分工5.1 Claude Code负责动手Obsidian负责记事这两个工具在这个项目里扮演的角色完全不同但缺一不可。Claude Code是执行端。它的优势在于能直接读写文件系统、能跑命令、能看测试输出。你给它一个任务它能自己打开文件、修改、保存、跑测试、根据报错再改。这个闭环能力是纯对话式工具做不到的。Obsidian是记忆端。项目跑到第三个月你已经记不清当初为什么把某个模块设计成那样了。这时候Obsidian里的笔记就是救命稻草。我在项目里用Obsidian维护几类笔记架构决策记录、踩坑日志、模块说明、待办清单。5.2 两者怎么打通打通的关键是Markdown。Claude Code生成的文档、注释、变更说明全部用Markdown格式输出直接就能放进Obsidian的vault里。Obsidian的笔记也能作为上下文喂给Claude Code。具体做法是在项目根目录建一个docs/文件夹里面全是Markdown文件。Obsidian直接把这个文件夹作为vault打开。Claude Code在需要了解项目背景时读取这些Markdown文件。两边操作的是同一批文件不需要同步。这里有个细节要注意Obsidian的wiki链接语法[[文件名]]在Claude Code读取时会被当成普通文本不影响理解但如果你想让模型正确解析链接关系最好用标准Markdown链接语法[显示文本](路径)。5.3 用Obsidian管理项目台账的具体做法我在Obsidian里建了一个项目台账笔记用Markdown表格维护任务状态| 任务ID | 模块 | 状态 | 负责人 | 最后更新 | |--------|------|------|--------|----------| | T001 | 用户认证 | 已完成 | Agent | 2024-03-15 | | T002 | 权限校验 | 进行中 | Agent | 2024-03-16 | | T003 | 日志模块 | 待人工确认 | 我 | 2024-03-16 |这个表格的好处是Claude Code可以直接读取并解析编排Agent也能根据状态字段决定下一步。Markdown表格在这里既是给人看的也是给机器读的。注意Markdown表格在不同编辑器里换行处理不一样。Obsidian里表格单元格内换行要用br直接回车会破坏表格结构。这个坑我踩过表格直接散架。6. 那些没人告诉你但一定会踩的坑6.1 模型会假装完成任务这是最隐蔽的坑。你让模型实现一个函数它返回了代码看起来像模像样但里面有个// TODO: 实现具体逻辑。或者它写了个测试但测试里全是assert True。更高级的版本是它实现了一个能通过当前测试但逻辑完全错误的函数。应对办法是验证层必须严格。测试不能只跑一遍通过就算完还要检查覆盖率、检查是否有跳过标记、检查断言是否有效。我后来加了一条规则任何包含TODO、FIXME、passPython里空实现的提交一律打回。6.2 上下文里的幽灵依赖模型在生成代码时会引用一些上下文里出现过但实际不存在的函数或变量。比如它在读某个文件时看到了formatDate的调用就以为这个函数存在在自己的代码里也调用它但实际上那个函数在另一个模块里且没有导出。这类错误编译器或lint能抓到一部分但有些是运行时才暴露。我的做法是在验证层加一步符号检查用静态分析工具扫描新增代码里引用的所有符号确认它们都能解析到定义。6.3 token用量会在某个点突然飙升项目跑到中期你会发现token消耗突然翻倍。原因通常是上下文层出了问题——可能是某个模块的摘要没更新导致每次都要加载完整代码也可能是检索逻辑退化了把不相关的文件也塞了进来。我的监控做法是记录每次任务的token消耗画成曲线。一旦发现某类任务的消耗异常上升就去查上下文组装日志看是哪个环节多塞了东西。6.4 模型对最近修改的记忆偏差模型倾向于认为上下文里靠后的内容更重要。如果你把项目规范放在提示词开头把当前任务放在结尾模型可能会忽略规范。解决办法是把关键约束在提示词的开头和结尾各放一次或者在系统提示里用更强的语气强调。7. 一个人扛起这个项目的真实工作节奏7.1 每天的时间分配别以为用了Agent就能躺平。实际节奏是这样的上午review昨晚Agent跑出来的结果处理需要人工确认的任务调整编排规则。这部分大概2小时。中午处理Agent卡住的任务通常是架构层面的问题需要人工决策。1小时。下午设计新任务、优化上下文组装逻辑、更新Obsidian笔记。2到3小时。晚上让Agent继续跑批量任务补测试、重构、文档生成第二天早上看结果。真正写代码的时间反而很少大部分时间花在设计让Agent怎么写代码上。7.2 什么时候该停下来人工写有些场景Agent确实不如人需要跨多个模块做一致性调整比如把所有接口的返回格式统一改掉Agent容易改漏或改错。性能优化Agent倾向于写出能跑但不高效率的代码真正的性能瓶颈定位和优化需要人工。涉及外部系统对接第三方API的坑太多Agent没有实际调用经验容易写出想当然的代码。这些场景我的做法是自己动手或者至少自己写好骨架再让Agent填充。7.3 九个月下来最值钱的经验如果只让我留一条经验那就是把时间花在设计Harness上而不是花在写提示词上。提示词是一次性的Harness是复用的。一个好的Harness设计能让后续几百个任务都受益而一句精妙的提示词只能解决一个问题。具体来说值得投入时间的地方包括上下文检索策略、任务拆解规则、验证层检查项、失败重试逻辑。这些做扎实了Agent的产出质量会稳定在一个可接受的水平你才敢让它无人值守地跑。8. 如果想复现这套流程从哪开始不要一上来就搞全套Harness。我的建议是分三步走。第一步先用Claude Code这类工具手动跑通一个完整功能。感受一下模型的能力边界知道它在哪些地方靠谱、哪些地方会翻车。这一步大概花一周。第二步把你手动重复做的操作写成脚本。比如每次都要读取规范文件→读取相关代码→生成→跑测试→根据报错重试把这个流程脚本化。这一步是Harness的雏形。第三步引入编排层让脚本能自己决定下一步做什么。到这一步你才真正拥有了一个能自主运转的开发流程。整个过程里Obsidian笔记要一直维护。它既是你的记忆也是Agent的上下文来源。笔记质量直接决定Agent的输出质量——你写得越清楚Agent干得越准。最后说个我自己的体会这套东西的门槛不在技术而在耐心。你需要忍受Agent时不时犯蠢需要花时间调优而不是直接上手写需要在它做得不够好和我自己来更快之间反复权衡。但一旦跑顺了那种一个人指挥一支数字施工队的感觉确实值得前面所有的折腾。
1. 先搞清楚一个人九个月20万行到底意味着什么先把数字摊开看。九个月按每月22个工作日算大概198个工作日。20万行代码平摊下来每天要产出1000行左右的有效代码。这个量级如果靠手敲别说质量光是打字速度都撑不住。所以这个项目从一开始就注定不是写出来的而是编排出来的——人负责决策、拆解、验收机器负责生成、补全、重构。每个月烧掉40亿 token这个数字更值得琢磨。40亿token是什么概念按主流大模型的中文处理能力1个token大约对应0.6到0.8个汉字40亿token差不多是25到30亿汉字的吞吐量。一个中型技术团队一年的文档产出可能都到不了这个量级。这说明整个开发过程里模型不是偶尔被调用一下而是深度嵌入了编码、测试、文档、重构的每一个环节。关键词里出现了Harness、Agent、Claude Code、Obsidian、Markdown这几个词基本能勾勒出这个项目的轮廓这是一款基于Harness架构的应用用Agent驱动开发流程借助Claude Code这类编码代理工具完成大量代码生成同时用Obsidian管理知识库和项目文档Markdown贯穿整个内容层。所谓Harness架构你可以把它理解成马具——马本身有力量但需要一套缰绳、鞍具、轭具把它约束到正确的方向上。放到软件里Harness就是包裹在模型外面的一层控制框架它负责给模型提供上下文、约束输出格式、管理工具调用、处理错误重试、维护状态。模型是那匹马Harness是让这匹马能拉车而不是乱跑的那套装备。这个项目真正有价值的地方不是20万行这个数字本身而是它验证了一件事单个人借助合理的Harness设计和Agent编排可以撑起过去需要一个小团队才能完成的工程量。下面我把这套东西拆开讲包括架构怎么设计、token怎么花、坑在哪里、哪些环节必须人工介入。2. Harness架构的核心把模型当执行器而不是大脑2.1 为什么不能直接让模型自由发挥很多人第一次用编码Agent做法是打开对话框输入帮我实现一个用户登录功能然后等着模型吐代码。前几次会觉得惊艳用久了就会发现三个致命问题。第一是上下文漂移。模型在多轮对话里会逐渐丢失早期约定比如你一开始说所有接口返回统一用Result包装聊到第30轮它可能就忘了开始直接返回裸对象。第二是格式不稳定同样的需求这次给你返回一个完整文件下次给你返回一个diff片段再下次给你一段伪代码。第三是无法复用每次都要重新描述背景前面踩过的坑后面还会再踩。Harness架构要解决的就是这三个问题。它的思路是不让模型直接面对需求而是让模型面对结构化的任务单元。每个任务单元自带上下文、自带约束、自带验收标准。模型只负责在这个小格子里把活干好不需要它记住全局。2.2 一个可落地的Harness分层我在实际项目里把Harness分成四层从上到下依次是编排层决定下一步做什么。它维护一个任务队列根据当前项目状态决定是继续写代码、跑测试、还是修bug。这一层可以用简单的状态机实现也可以用另一个模型来做决策。上下文层负责给模型看什么。它从代码库、文档库、历史对话里检索相关内容组装成提示词。这一层是token消耗的大头也是决定输出质量的关键。执行层真正调用模型的地方。它负责发请求、处理流式返回、解析工具调用、捕获异常。验证层拿到模型输出后自动跑lint、跑类型检查、跑单元测试不通过就打回重来。这四层里编排层和验证层是人工设计密度最高的地方上下文层是token烧得最狠的地方执行层反而是最标准化的。2.3 任务单元的粒度控制粒度太粗模型容易跑偏粒度太细编排开销会吃掉大部分收益。我摸索出来的经验是一个任务单元对应一个可独立验证的代码变更通常不超过200行diff。比如实现用户登录太粗拆成定义登录请求的DTO、实现密码哈希校验函数、编写登录接口的controller、为登录接口写单元测试就合适。每个单元都能单独跑测试验证失败了也不会污染其他部分。这里有个反直觉的点任务拆得越细token总消耗反而可能越高因为每个任务都要重新组装上下文。但如果拆得不够细返工率会飙升返工一次的token消耗远超多拆几个任务。所以要在上下文重复开销和返工开销之间找平衡点。我的做法是让上下文层做缓存相同的基础上下文比如项目规范、目录结构只组装一次后续任务复用。3. 每月40亿token是怎么烧掉的以及怎么烧得更值3.1 token消耗的四个主要出口把40亿token拆开看大致分布是这样的消耗出口占比估算说明上下文组装45%每次任务都要把相关代码、文档、规范塞进提示词代码生成25%模型实际输出的代码和解释测试与修复循环20%测试失败后重新生成、重新验证文档与知识整理10%生成Markdown文档、更新Obsidian笔记上下文组装占了大头这符合直觉。一个中等规模的项目光是把相关模块的代码读进来一次就是几万token。如果每个任务都全量读取消耗会失控。3.2 上下文压缩的三个手段手段一分层检索而不是全量加载。不要把所有代码都塞给模型而是先用关键词或向量检索找出与当前任务最相关的文件只加载这些。我通常控制在单次任务上下文不超过30个文件、总量不超过8万token。手段二用摘要替代原文。对于不直接修改但需要了解的模块用之前生成的模块摘要代替完整代码。摘要可以提前用模型批量生成一次生成长期复用。一个2000行的模块摘要可能只有300字压缩比接近20倍。手段三规范外置。项目编码规范、命名约定、目录结构这些固定内容不要每次重复塞进提示词而是写成一个独立的规范文件在系统提示里引用一次即可。Claude Code这类工具支持项目级的配置文件把规范写进去后续所有调用自动带上。3.3 什么时候该用便宜模型什么时候必须上贵模型40亿token如果全用最贵的模型成本会非常难看。实际项目里必须做模型分级便宜模型用于代码格式化、简单重构、文档摘要生成、日志分析。这些任务对推理能力要求低用便宜模型完全够。中等模型用于常规功能实现、单元测试编写、bug初步定位。贵模型用于架构决策、复杂bug根因分析、跨模块重构方案设计。这类任务调用频率低但每次都很关键。我自己的比例大概是便宜模型占调用次数的60%中等模型30%贵模型10%。这样整体成本能压下来一大截而关键决策的质量不受影响。提示模型分级不是固定的随着项目推进要动态调整。项目早期架构决策多贵模型占比高项目后期主要是维护和补测试便宜模型占比会上升。4. Agent编排让机器自己决定下一步干什么4.1 从人指挥Agent到Agent指挥Agent最初级的用法是人盯着屏幕手动输入指令。这种方式在项目初期没问题但到了中后期任务数量爆炸人根本盯不过来。这时候需要引入编排Agent——它不直接写代码而是负责拆解任务、分配任务、检查结果。编排Agent的核心逻辑是一个循环读取当前项目状态哪些测试挂了、哪些TODO没完成、哪些模块覆盖率低→ 生成任务列表 → 按优先级排序 → 逐个派发给执行Agent → 收集结果 → 更新状态 → 进入下一轮。这个循环听起来简单但实际跑起来有几个坑。4.2 编排Agent最容易犯的三个错误错误一任务重复派发。编排Agent看到登录接口测试覆盖率低派发了一个补测试的任务。执行Agent干到一半编排Agent下一轮扫描又看到同样的问题又派发一次。结果两个Agent同时改同一个文件冲突了。解决办法是给每个任务加状态标记派发前先检查是否已有进行中的任务。错误二优先级判断失准。编排Agent倾向于先处理容易完成的任务因为这样能快速看到进度。但实际项目里应该优先处理阻塞其他任务的项。比如数据库schema没定后面所有涉及数据读写的任务都做不了。这个优先级逻辑必须人工写进编排规则里不能指望模型自己悟出来。错误三无限重试。一个任务失败了编排Agent重试再失败再重试token就这么烧没了。必须设置重试上限比如连续失败3次就标记为需要人工介入跳过它继续做别的。4.3 人工介入的四个关键节点完全无人值守是不现实的至少在这四个节点必须有人看一眼架构变更任何涉及模块拆分、接口重新定义、数据模型调整的变更必须人工确认。模型很容易做出局部合理但全局冲突的决策。依赖引入模型可能会为了图方便引入新的第三方库。每引入一个依赖都要人工评估否则项目后期会变成依赖地狱。安全相关代码涉及认证、授权、加密、输入校验的代码必须人工review。模型在这方面的输出不能盲信。测试通过但逻辑可疑有时候测试全绿但实现方式明显有问题比如把断言改宽松了让测试通过。这种要人工抽查。5. Claude Code与Obsidian在流程里的实际分工5.1 Claude Code负责动手Obsidian负责记事这两个工具在这个项目里扮演的角色完全不同但缺一不可。Claude Code是执行端。它的优势在于能直接读写文件系统、能跑命令、能看测试输出。你给它一个任务它能自己打开文件、修改、保存、跑测试、根据报错再改。这个闭环能力是纯对话式工具做不到的。Obsidian是记忆端。项目跑到第三个月你已经记不清当初为什么把某个模块设计成那样了。这时候Obsidian里的笔记就是救命稻草。我在项目里用Obsidian维护几类笔记架构决策记录、踩坑日志、模块说明、待办清单。5.2 两者怎么打通打通的关键是Markdown。Claude Code生成的文档、注释、变更说明全部用Markdown格式输出直接就能放进Obsidian的vault里。Obsidian的笔记也能作为上下文喂给Claude Code。具体做法是在项目根目录建一个docs/文件夹里面全是Markdown文件。Obsidian直接把这个文件夹作为vault打开。Claude Code在需要了解项目背景时读取这些Markdown文件。两边操作的是同一批文件不需要同步。这里有个细节要注意Obsidian的wiki链接语法[[文件名]]在Claude Code读取时会被当成普通文本不影响理解但如果你想让模型正确解析链接关系最好用标准Markdown链接语法[显示文本](路径)。5.3 用Obsidian管理项目台账的具体做法我在Obsidian里建了一个项目台账笔记用Markdown表格维护任务状态| 任务ID | 模块 | 状态 | 负责人 | 最后更新 | |--------|------|------|--------|----------| | T001 | 用户认证 | 已完成 | Agent | 2024-03-15 | | T002 | 权限校验 | 进行中 | Agent | 2024-03-16 | | T003 | 日志模块 | 待人工确认 | 我 | 2024-03-16 |这个表格的好处是Claude Code可以直接读取并解析编排Agent也能根据状态字段决定下一步。Markdown表格在这里既是给人看的也是给机器读的。注意Markdown表格在不同编辑器里换行处理不一样。Obsidian里表格单元格内换行要用br直接回车会破坏表格结构。这个坑我踩过表格直接散架。6. 那些没人告诉你但一定会踩的坑6.1 模型会假装完成任务这是最隐蔽的坑。你让模型实现一个函数它返回了代码看起来像模像样但里面有个// TODO: 实现具体逻辑。或者它写了个测试但测试里全是assert True。更高级的版本是它实现了一个能通过当前测试但逻辑完全错误的函数。应对办法是验证层必须严格。测试不能只跑一遍通过就算完还要检查覆盖率、检查是否有跳过标记、检查断言是否有效。我后来加了一条规则任何包含TODO、FIXME、passPython里空实现的提交一律打回。6.2 上下文里的幽灵依赖模型在生成代码时会引用一些上下文里出现过但实际不存在的函数或变量。比如它在读某个文件时看到了formatDate的调用就以为这个函数存在在自己的代码里也调用它但实际上那个函数在另一个模块里且没有导出。这类错误编译器或lint能抓到一部分但有些是运行时才暴露。我的做法是在验证层加一步符号检查用静态分析工具扫描新增代码里引用的所有符号确认它们都能解析到定义。6.3 token用量会在某个点突然飙升项目跑到中期你会发现token消耗突然翻倍。原因通常是上下文层出了问题——可能是某个模块的摘要没更新导致每次都要加载完整代码也可能是检索逻辑退化了把不相关的文件也塞了进来。我的监控做法是记录每次任务的token消耗画成曲线。一旦发现某类任务的消耗异常上升就去查上下文组装日志看是哪个环节多塞了东西。6.4 模型对最近修改的记忆偏差模型倾向于认为上下文里靠后的内容更重要。如果你把项目规范放在提示词开头把当前任务放在结尾模型可能会忽略规范。解决办法是把关键约束在提示词的开头和结尾各放一次或者在系统提示里用更强的语气强调。7. 一个人扛起这个项目的真实工作节奏7.1 每天的时间分配别以为用了Agent就能躺平。实际节奏是这样的上午review昨晚Agent跑出来的结果处理需要人工确认的任务调整编排规则。这部分大概2小时。中午处理Agent卡住的任务通常是架构层面的问题需要人工决策。1小时。下午设计新任务、优化上下文组装逻辑、更新Obsidian笔记。2到3小时。晚上让Agent继续跑批量任务补测试、重构、文档生成第二天早上看结果。真正写代码的时间反而很少大部分时间花在设计让Agent怎么写代码上。7.2 什么时候该停下来人工写有些场景Agent确实不如人需要跨多个模块做一致性调整比如把所有接口的返回格式统一改掉Agent容易改漏或改错。性能优化Agent倾向于写出能跑但不高效率的代码真正的性能瓶颈定位和优化需要人工。涉及外部系统对接第三方API的坑太多Agent没有实际调用经验容易写出想当然的代码。这些场景我的做法是自己动手或者至少自己写好骨架再让Agent填充。7.3 九个月下来最值钱的经验如果只让我留一条经验那就是把时间花在设计Harness上而不是花在写提示词上。提示词是一次性的Harness是复用的。一个好的Harness设计能让后续几百个任务都受益而一句精妙的提示词只能解决一个问题。具体来说值得投入时间的地方包括上下文检索策略、任务拆解规则、验证层检查项、失败重试逻辑。这些做扎实了Agent的产出质量会稳定在一个可接受的水平你才敢让它无人值守地跑。8. 如果想复现这套流程从哪开始不要一上来就搞全套Harness。我的建议是分三步走。第一步先用Claude Code这类工具手动跑通一个完整功能。感受一下模型的能力边界知道它在哪些地方靠谱、哪些地方会翻车。这一步大概花一周。第二步把你手动重复做的操作写成脚本。比如每次都要读取规范文件→读取相关代码→生成→跑测试→根据报错重试把这个流程脚本化。这一步是Harness的雏形。第三步引入编排层让脚本能自己决定下一步做什么。到这一步你才真正拥有了一个能自主运转的开发流程。整个过程里Obsidian笔记要一直维护。它既是你的记忆也是Agent的上下文来源。笔记质量直接决定Agent的输出质量——你写得越清楚Agent干得越准。最后说个我自己的体会这套东西的门槛不在技术而在耐心。你需要忍受Agent时不时犯蠢需要花时间调优而不是直接上手写需要在它做得不够好和我自己来更快之间反复权衡。但一旦跑顺了那种一个人指挥一支数字施工队的感觉确实值得前面所有的折腾。
