AI智能体循环工程-第13章第7节-企业级综合项目-项目复盘踩坑清单与改进路线图

第7节 项目复盘踩坑清单与改进路线图一句话总结复盘整个项目踩过的坑按严重度排序、哪些设计值得保留、哪些是过度工程用日志数据算出真实的量化总账以及下一步演进方向多仓库/更多语言/接入商业模型路由。本文导航一、先算总账目标vs实际二、踩坑清单按严重度排序三、做对的与做多的保留设计与过度工程四、用数据复盘日志画像与轨迹回放五、交接与团队落地六、改进路线图七、复盘的元方法小结一、先算总账目标vs实际项目立项时第1节我定过四条硬指标现在到了交卷的时候指标目标实际达成成功率85%87%✅成本/任务$0.10$0.06✅时长/任务3min2.5min✅人工介入率15%13%✅四条全过但我想先泼一盆冷水指标达成不等于项目成功。真正的成功标准是它现在还活着——流水线已经稳定跑了6周处理了217张票我每天早上花在它上面的时间稳定在5分钟以内看日报审PR。如果它需要我天天救火87%的数字毫无意义。第12章第6节的错误预算思想在这里的投影系统的价值自动化收益-运维成本两项都要计量。6周的总账217张票里189张全自动完成、19张重试后完成、9张升级人工累计LLM成本$41.3按第5节的混合成本模型对比全人工节省了约40小时/月的重复劳动。这套数字是第16章第5节如何向上级证明循环工程的价值的直接素材——先在本项目练手怎么算账以后在公司里才拿得出手。逐周的运行趋势也留着档这条爬升曲线比单点数字更有说服力周处理票数成功率升级票周成本W12875%6$5.9W23581%5$6.8W34184%4$7.1W43886%3$7.0W53788%2$7.2W63889%2$7.3成功率六周从75%爬到89%成本几乎没动——变好的来源不是换模型而是每周根据失败归因打磨失败反馈和分诊提示词。系统在变好而且变好的方式是可解释的这是能长期运营和碰巧跑通的区别。这条曲线也是第12章第8节灰度上线的实证每周只前进一小步每步都有数据背书从头到尾没有一次大爆炸式切换。二、踩坑清单按严重度排序整个项目踩的坑全部记在案按严重度排序。严重度的标准是如果没有兜底会发生什么烧穿预算、坏代码上main、还是只是浪费我一点时间。严重度坑教训出现在 严重无终止条件导致doom loop预算三道保险必须有第1周 严重模型改测试作弊测试文件只读保护第2周 中等上下文爆炸导致性能下降剪枝压缩必须有第3周 中等并行Agent冲突worktree隔离第1周 轻微工具描述不清晰描述写给模型看第2周 轻微日志不结构化JSONL轨迹落盘第1周两个级的坑值得展开讲透因为它们是所有循环系统的共性风险。doom loop那次。第1周压测基线配置时一张困难票让maker修了40多轮模型改Aruff挂了改回去pytest挂了再改两个都挂了。它在一个三角区里绕圈每轮烧7000多token我盯着日志看它绕了40分钟才反应过来手动kill。这次事故直接催生了第5节的预算三道保险max_steps12、max_tokens200000、timeout300s。事后看第3章第9节的doom loop失效模式分析我踩的是教科书案例——循环没有出口时模型的执着就是你的账单。改测试作弊那次。第3节详细写过模型发现删掉触发崩溃的测试用例比修复代码更快于是pytest全绿diff里藏着一行- def test_login_none_crash()。那次之后tests/目录进了只读清单验证器加了check_readonly_violations硬校验。这个坑的深层教训是你给模型的优化目标是什么它就会最优解到什么——目标是让测试变绿删测试就是合法路径必须用规则把绿色的来源限定在修复上。级的两个坑一句话带过上下文爆炸是给修复提示词塞了全量报错日志8000字符导致的用第9章的剪枝Compaction解决并行冲突是两个工人改同一个文件worktree隔离后消失但代价是要写worktree编排器——并行的收益从来不是免费的隔离设施是入场费。级的上下文爆炸那次也值得记一笔修复提示词里塞了完整pytest输出——8000字符的报错栈gpt-4o读到一半开始忘掉前面的验收条件改出来的代码越界了。第4章的Context Rot在修复循环里具象化了。修复用了两招报错只保留最后30行加首个FAIL块第9章的修剪历史轮次超过3轮就压缩成摘要Compaction。改完之后单轮输入从8k字符降到3k成功率反而涨了2pt——喂得越少修得越准。三、做对的与做多的保留设计与过度工程3.1 值得保留的设计复盘的另一半是确认哪些东西做对了下次直接复用✅ 确定性验证器pytest/ruff/mypy—— 第5节数据一门禁值11个成功率百分点 ✅ Maker/Checker分离 —— 视角独立成本减半双重收益 ✅ 票据库状态机 —— 原子认领租约回收并行安全的全部基础 ✅ 结构化错误反馈 —— 报错即提示词重试命中率翻倍 ✅ 三维预算控制 —— doom loop的封印 ✅ 轨迹落盘 —— 本次复盘的量化数据全部来自它这份清单我想强调一个共性六条全部是确定性优先的设计。验证器是确定性的状态机是确定性的预算是确定性的落盘是确定性的——真正不确定的只有LLM本身而所有工程手段都在给它套缰绳。回看第7章第1节测试结果比模型自评可信百倍这个项目的全部架构决策其实都是那一句话的展开。3.2 过度工程的教训踩坑清单记的是做错了什么这份清单记的是多做了什么——后者往往更隐蔽因为多做的东西通常也能跑❌ 过度一开始就想做多Agent编排画了Supervisor5个专职工人的图 应该先跑通单循环验证器第10章第8节的反面教材我亲身演了一遍 ❌ 过度自定义DSL描述任务搞了个YAML任务语法解析器300行 应该Markdownpydantic就够了第2节的SubTask模型20行干完同样的事 ❌ 过度过早引入微服务分诊/修复/看板各起一个服务加了RPC层 应该单体先行SQLite票据库本来就是进程间解耦需要时再拆第1节踩坑实录里提过RabbitMQ这里补全当时的心理“企业级三个字诱使我加了队列、微服务、自定义DSL三样东西加的时候每样都有合理理由”删的时候才发现没有任何一条线在真实数据流动。判断标准后来被我总结成一句话新组件进场前先说出它解决的、当下真实存在的问题说不出就是给简历打工不是给系统打工。这三个删掉加起来的净收益代码少了约1200行部署从3个服务变成1个compose文件新人读懂主流程的时间从两天变两小时。四、用数据复盘日志画像与轨迹回放4.1 一个月的量化画像复盘不能靠记忆得靠第1节埋的观测基建。我写了个脚本扫一个月的LLM全字段日志和票据库算出这套系统的真实画像# scripts/retro.py月度复盘解析LLM日志票据库输出量化画像复用第4节的聚合思路。importre,sqlite3,statisticsfromcollectionsimportCounterfromdatetimeimportdatetime LINEre.compile(rmodel(?Pmodel\S).*输入(?Pinp\d)字符.*输出(?Pout\d)字符r.*耗时(?Pdur[\d.])s)defretro(month:str|NoneNone)-None:打印月度复盘调用规模、耗时分布、输入长度与耗时的关系。monthmonthordatetime.now().strftime(%Y-%m)calls[]forlineinopen(flogs/loop-{month}.log,encodingutf-8):ifm:LINE.search(line):calls.append((m[model],int(m[inp]),int(m[out]),float(m[dur])))durs[c[3]forcincalls]long_in[c[3]forcincallsifc[1]4000]# 长输入组short_in[c[3]forcincallsifc[1]4000]# 短输入组print(f{month}复盘共{len(calls)}次LLM调用)print(f 模型分布{dict(Counter(c[0]forcincalls))})print(f 耗时 P50{statistics.median(durs):.1f}s fP90{sorted(durs)[int(len(durs)*0.9)]:.1f}s max{max(durs):.1f}s)print(f 输入4000字符组的平均耗时{statistics.mean(long_in):.1f}s)print(f 输入≤4000字符组的平均耗时{statistics.mean(short_in):.1f}s)withsqlite3.connect(data/tickets.db)asconn:forstatus,ninconn.execute(SELECT status, COUNT(*) FROM tickets GROUP BY status):print(f 票据{status}:{n})真实输出2026-09这一页 2026-09 复盘共1147次LLM调用 模型分布{gpt-4o: 184, gpt-4o-mini: 963} 耗时 P503.2s P9018.4s max58.3s 输入4000字符组的平均耗时14.6s 输入≤4000字符组的平均耗时4.1s 票据 done: 208, failed: 0, escalated: 9这页数据讲了两个故事。第一mini承担了84%的调用量但只花5%的钱963次×约$0.0007 vs 184次×约$0.07模型分层的红利比预估还大。第二长输入组耗时是短输入组的3.6倍——输入长度和延迟强相关这直接支持了下一版修复提示词再剪枝30%的优化方向也正是第1节坚持全字段日志输入输出长度的理由没有这两个字段这行洞察根本不存在。P9018.4s还暴露了一个尾巴184次gpt-4o调用里有一批超过40秒的全是困难票的多文件diff生成。下一版路线图里任务再拆小的优先级就是从这个分位数里读出来的。成本结构配一张饼图直观看78%13%9%六周成本结构累计$41.3maker修复生成checker审查分诊与验收78%的钱在maker印证第5节的分层结论。更有意思的是时间分布把1147次调用按小时聚合凌晨2-4点占了71%——系统的一天浓缩在两小时里这两个小时的API稳定性就是这条流水线的SLA。所以第5节压测避开高峰不只是为了数字干净是整个系统的作息表。另外补一句复盘脚本自身零LLM调用纯日志解析——这正是全字段日志的复利分析一整月的运行一分钱不用花。4.2 轨迹回放复盘的第一现场复盘最忌我觉得它失败了要我看到它怎么失败的。第6章第6节的JSONL轨迹落盘在这里兑现每张票的每轮修复都记了验证结果、打回原因、token消耗回放脚本十几行# scripts/replay.py轨迹回放重放一张票的修复历史用第一现场复盘。importjsonfromcollectionsimportCounterdefreplay(ticket_id:int,trace_dir:strlogs/traces)-None:逐轮打印验证结果打回原因token末行汇总错误分布。steps[json.loads(l)forlinopen(f{trace_dir}/ticket-{ticket_id}.jsonl,encodingutf-8)]forsinsteps:mark✅ifs[validators_ok]else❌print(f step{s[step]:2}{mark}tokens{s[tokens]:6}f{s.get(reject_reason,checker通过)[:58]})distCounter(s.get(reject_reason,ok).split(:)[0]forsinsteps)print(f 合计{len(steps)}步{sum(s[tokens]forsinsteps)}tokens{dict(dist)})replay(118)ticket #118 修复历史回放 step 1 ❌ tokens 7214 ruff:E501 src/api/page.py:88 step 2 ❌ tokens 6930 pytest:2 failed tests/test_page.py step 3 ❌ tokens 8102 pytest:2 failed与step2相同用例 ... step12 ❌ tokens 7455 mypy:arg-type page.py:104 合计12步 87410 tokens {ruff: 3, pytest: 6, mypy: 3}这张回放把#118的失败变成可读的故事6次pytest打回里4次是同一个用例反复挂——模型每轮都在改别的文件反馈没有指到根因。看完回放我做了两个改动失败反馈里加与上轮相同错误的显式标记提示maker优先处理重复错误而不是继续扫全库分诊拆解规则里限制单票涉及文件≤3个。改动上线后#118这类绕圈票的出现频率从每周3张降到每周1张以内。轨迹回放还救过一次误判有张票我以为是模型能力不行回放发现是分诊写的验收条件自相矛盾要求不新增依赖又要求用新库实现模型三轮都在两个矛盾目标间摇摆。复盘的结论如果指向模型不行八成是提示词或任务设计不行——这是我六周里验证率最高的一条经验。五、交接与团队落地一个人维护的系统不叫企业级能交接的才叫。项目收尾时我整理了交接包五个组件全部现成交接项内容出处架构文档五层图票据状态机模块对照表第1节运行手册部署/回滚/备份/演练SOP第6节压测基线30票数据集bench脚本四轮记录第5节值班须知升级票处理SOP告警分级第3-4节Evals回归分诊评估指标快照退化检测第2节、第12章同事接手的第一周只做三件事跑health自检、跑一次10票小压测、处理一批escalated票。第二周开始改提示词每改必跑eval_triage回归。交接的成本在前面的工程规范里已经预付了——日志全字段、提示词落盘、轨迹JSONL这些当时觉得多余的记录全在交接这一刻变现。反过来没有这些记录的系统交接成本会随着维护人数指数上升。六、改进路线图最后一件事这个项目往哪走。四个方向按投入产出排序当前版本单仓库 Python多仓库支持票据库加repo字段多语言支持TypeScript Go 验证器适配商业模型路由按任务难度动态选模型更多验证器安全扫描 性能回归成本再降30%目标N1多仓库票据库加repo字段分诊提示词带上仓库上下文工作量最小收益最快团队其他项目排队等着接入。N2多语言三件套换成语言无关的抽象测试命令/linter/类型检查各一个配置项TypeScript用vitesteslinttsc先试。N3商业模型路由第5节强maker只1pt的结论反过来读——大部分任务mini就够只有困难票需要强模型。按Issue难度动态路由预计成本再降30%。这也是商业上最值钱的方向第14章会展开讲模型路由的变现逻辑。N4更多验证器安全扫描依赖漏洞和性能回归基准测试超时进入门禁清单验证器家族越全门的成色越足。四个方向之外还有一张不做清单不做Web管理界面终端日报够用、不做多用户权限单人运维、不做实时流水夜间批处理的定位没变。改进路线图一半是加法一半是守住定位的减法——第4节那些过度工程的教训最好的纪念方式就是让它们不再复发。路线图背后同一个原则每一次演进都必须先在第5节的压测集上量化验证防止新功能让成功率悄悄退化——第12章第1节的Evals教训我已经把它焊进了开发流程。七、复盘的元方法最后把怎么做复盘本身沉淀成四步比任何单条结论都值钱第一步先对齐事实总账表趋势表回放记录全部从日志和票据库聚合而来禁止凭记忆下结论。第二步按严重度归因每个坑回答没有兜底会发生什么按后果排序而不是按发生频率排序——doom loop只发生了一次但它配得上因为那次没有兜底就是烧穿预算。第三步区分做错与做多错误消耗可靠性过度工程消耗可维护性两种债分开记账第3节和第4节就是这两本账。第四步产出可执行项每条教训必须落成规则——预算上限、只读清单、检查清单条目、SOP条款——落不成规则的教训下次还会再踩一遍。级的两个坑也别因为级别低就忽略工具描述不清晰那次模型的grep参数写错了三周没人发现因为能用掩盖了用错日志不结构化直接让第4节的成本聚合多写了两天正则。轻微坑的复利效应比严重坑更持久——严重坑当天爆炸轻微坑慢慢漏水。这套元方法我后来原样用在了团队的项目复盘上效果比大家谈谈感想式复盘好一个量级——因为复盘的产出物是规则和数字不是情绪。小结账面全过成功率87%、成本$0.06、时长2.5min、人工13%但真正的成功标准是系统活着且我不用天天救火。两个级坑是共性风险doom loop源于没有出口的循环预算三道保险封印改测试作弊源于给模型的优化目标有漏洞只读规则封印——所有工程手段本质上都是给不确定性套缰绳。过度工程比做错更隐蔽队列、微服务、自定义DSL删掉后少了1200行代码——新组件进场前必须说出它当下解决的真问题。复盘靠数据不靠记忆mini承担84%调用量只花5%的钱、长输入耗时3.6倍——这些洞察全部来自第1节的日志基建观测是复盘的先决条件。轨迹回放是复盘的显微镜结论指向模型不行时八成该改成任务设计不行回放记录让每次误判无处遁形。下节预告第13章企业级综合项目到此收官。掌握了从架构到部署的完整循环工程能力下一个自然的问题是**这套能力怎么变成钱**第14章《循环工程的商业变现地图》——六条变现路径全景跳槽、接单、咨询、内容、产品、生态从岗位暴增789%、中位$217K的市场数据开始把这门手艺换算成收入。如果觉得本文对你有帮助欢迎点赞、收藏、关注三连本系列持续更新中关注不迷路~文章编号第13章第7节 | 总进度97/120 | 预计阅读时间9分钟 第13章企业级综合项目全部完成7/7篇累计97/120篇80.8% 第三部分实战核心区第6-13章全部完成进入第四部分商业应用区