TL;DR代理擅长执行、弱在规划——HN 高赞经验里的这个判断，正是遗留代码重构的正确分工依据：阶段一让 Codex 当考古学家（只读不写，产出结构文档），阶段二才当工人（按你确认的计划小步改）。
来源信号 SOURCES
以下内容整理自社区公开讨论，本页只做拆解与核实，不搬运原帖；观点归属原作者。
Hacker News · Ask HN: Do you have any evidence that agentic coding works?（461 pts）查看原帖 ↗Hacker News · Codex for almost everything（1001 pts）查看原帖 ↗
事实性知识 FACTS
这些是讨论中被多方印证、或可对照官方文档核实的事实。
- HN 461 pts 讨论中获高共鸣的经验判断：代理无法在高层提前规划，因此对系统设计存在盲区；把规划留给人、执行交给代理是反复出现的应对。
- Codex 具备全仓库阅读与跨文件检索能力，可产出调用关系、依赖清单等理解性文档（阅读型任务无需写入权限）。
概念性知识 CONCEPTS
社区讨论里的概念不全是事实——每条都标注了它的性质，读之前先看标签。
两阶段切分个人观点
阶段一「考古」：只读，产出模块地图、依赖清单、风险点列表；阶段二「施工」：人把地图转成有顺序的重构计划，Codex 按计划小步执行。两个阶段不混，是规避设计盲区的直接手段。
小步与安全网个人观点
社区共识的施工纪律：每步一个可验证的变换，配测试或可回滚。两阶段法产出的依赖清单恰好用来决定「先动哪里最安全」。
理解也是资产待验证假设
阶段一的产出（模块地图）本身就是团队资产：新人上手、文档欠账都能用它偿还。这让「花半天只读不写」有了独立的回报。
知识梳理 TAKEAWAYS
为什么不让 Codex 直接「把这个模块重构好」：HN 高赞经验给出的机制解释是代理不会先问「为什么这样设计」，它会把表面模式优化掉，把隐含约束一起破坏。先考古后施工，本质是把「问为什么」的环节还给人。
阶段一的验收标准可以很具体：让 Codex 产出「改这个函数会影响哪些调用方」的清单，随机抽三个调用点人工核对。全对，地图才可信；有错，就缩小范围重做。
阶段二的任务粒度以「一次提交能讲清楚」为限：改一处、跑测试、提交。粒度一大，代理的设计盲区就会重新渗进来。
什么时候可以打破两阶段：改动面只有一个文件、无外部调用方的小重构，直接让 Codex 一步做完并跑测试即可——盲区风险与影响面成正比。
看完之后 NEXT
想知道今天的重置判定？回到 首页实时雷达。