问一个AI coding agent,在全新项目里加一个"职位状态"字段,它会准确交出一个。问同样的问题,在一个跑了四年的系统里,它常常会发明出第四种拼法——因为这个概念本来就已经用三种说法混着叫,系统自己都没决定过哪个是真的。
开发者Ernest Bednarczyk在博客里把这个现象讲透了:AI在greenfield项目里好用,一进重耦合、堆满技术债的老代码库就露怯。他的判断是,问题不在模型能力,而在代码库从来没有对"这个词是什么意思、谁拥有这块地盘"达成过共识。模型只能猜,猜得还经常错。
他开的药方:把共识写进仓库
他的解法是借DDD(领域驱动设计)的老底子,给每个仓库配一份.workflow.json清单和一份CONTEXT.md术语表,声明这个仓库归哪个业务边界、和邻居仓库是什么关系、谁的模型说了算。工程工作被他拆成两半:strategic(人来决定改什么、为什么改)和tactical(agent来落地、出PR),前者贵,后者已经变得很便宜。
最值得留意的设计,是他让边界的两侧各自申报关系,再用脚本比对是否吻合——一方声明"我是供应者",另一方声明"我在这里做防腐层",两边对不上就自动开issue。这比传统架构文档聪明的地方在于,它把"文档漂移"从人工巡检变成了机械校验。
诊断精准,回响却很冷
这套方案讲得有条理,命中的又是行业公认的痛点。奇怪的是它几乎没被人接住:发到Hacker News上,只拿到约29个点赞和4条评论;Reddit上唯一的转发帖,评论区空空如也。
这不只是一篇冷帖的运气问题。它更像在提示,这类关于"agent与领域语义"的方法论,目前根本没有被量化验证的渠道。业内常用的agent能力基准——SWE-bench评的是单个issue能不能出一个能过测试的patch,RepoBench测的是跨文件检索和补全能力,连专门盯着技术债迁移的SWE Refactor Bench,也只区分"行为对不对"和"迁移完不完整"两个维度——没有一个基准去衡量"这个仓库的领域边界是不是被agent正确理解了"。
也就是说,这不是一个被否定的想法,而是一个还没被检验的想法。行业没有工具去证明它对,也没有工具去证明它错。
这份清单本身也可能变成债务
这套manifest体系的漏洞,恰恰藏在它想解决的问题里。它靠人工声明边界、靠人工维护术语表,而人工维护正是"技术债"这个词最早的来源。一份过时的.workflow.json,给agent的不是缺失信息,而是错误信息——agent会带着错误的自信去改代码,这比什么都不知道更危险。
- 风险.过时的领域清单会让agent"自信地猜错",比完全没有清单更难察觉。
作者提出的strategic(人决定)和tactical(agent实现)二分法也过于干净。真实的实现过程常常会反向暴露新的问题——并发冲突、性能约束、当初想岔了的需求——这些东西不是先想清楚再交给agent打字就能避开的,"打字"从来不是纯机械劳动。
双向声明校验能做的,也只是证明两份声明彼此吻合,不能证明声明本身反映了真实的运行时行为。一致性检查抓得住"说法不一样",抓不住"说法都错了"。
一致性不等于正确性,这是这套方法论最没解决的一句话。
再往外看一层,这篇文章几乎没提操作安全——谁有权限改manifest、代码库内容会不会诱导agent走偏、迁移出错怎么回滚,这些都是空白。而且如果agent产出变更的速度超过人类重建理解的速度,瓶颈根本不会消失,只会从"写代码"挪到"看得懂PR",审查质量反而可能下滑。
该盯住的下一步
这套方法论目前只有作者自己两个仓库的招聘追踪器做样本,没有缺陷率、审查耗时、token成本这些对照数据,连是不是能在几百个服务、多团队的真实企业代码库里跑通,都还没人试过。
真正值得等的,不是又一篇类似的个人博客,而是有没有人拿它跟"无文档""传统架构文档"两种对照组做真实的agent工程实验——如果manifest省下的实现时间,最终被维护它的成本吃掉,这就是技术债换了个地方存在,不是被还清了。