想让 Codex 一次写对代码，需求到底该说得多清楚？
1 Codex 并没有“听懂”你的话，它只是在补全“最像”的下一段代码
你有没有经历过这个时刻：让它加一个导出功能，它一口气把代码写完，告诉你 done，你点开文件，中文全是乱码。它没有偷懒，也不是不知道编码这回事。真正的原因是，你心里那句“导出当然要处理中文不乱码”，从头到尾没有出现在它眼前。它不猜，也猜不到。这不是表达问题，是这类工具的工作机制决定的。把机制看清楚，你才知道需求要说到什么程度，才能让它稳定地一次写对。
先看最底层的模型在做什么。它读到的所有东西都是一长串文字：你的需求、仓库里的文件、之前几轮对话。它对这串文字做的唯一一件事，是预测“下一个最可能出现的词”是什么，然后一个词一个词地把答案写出来。这套机制有个学名，叫自回归 next-token prediction（逐词预测）。写代码和写散文对它是同一件事：顺着上文，把最像的下文续出来。
用输入法打比方最直观。你在聊天框里打出“我今”，输入法接“天”；打出“写个函”，它接“数”。它不知道你为什么打这些字，也不关心你想表达什么，它只是顺着你已经打出的内容，接出统计上最顺的下一步。如果你上一句的宾语没打完，它绝不会替你脑补你要说的那个词，因为那个词不在它的条件里。Codex 同理：它不是先“理解你的目标”再动手，而是在补全“如果有个程序员拿到你这串上下文，最可能写出什么样的下一段代码”。GPT-3
这套机制的经典表述，来自 2020 年 OpenAI 的 GPT-3 论文。你想让模型干一件新任务，唯一的方法是把任务描述和几个示范写进输入文本，这叫 few-shot（少样本）。全程不更新任何权重，对模型的“教育”只能通过文字完成。论文还自己承认了两件事：一是把任务硬压成一个“预测问题”，不等于让模型去做目标导向的行动；二是模型到底是真学会了任务，还是在识别训练时见过的相似模式，连作者都无法区分。把这条机制从 GPT-3 搬到今天的 Codex，属于教程层面的推论，因为论文本身不涉及代码。但这个推论能解释你每天看到的几乎所有现象，尤其是这一条：需求里没写明的点，不是它没想到，而是对它不存在。对人说话可以漏一半，他会追问、会脑补；对 Codex，凡是没进入上下文的约束，物理上就不在它的决策条件里。用一张图把这条机制钉下来：
你打的每一个字、给的每一个示例，都只是改变模型面前的条件文本；它拿这串文字当条件，吐出概率最高的续写。所以“说清楚需求”的本质，是把约束写进它看得见的条件里，而不是指望它读懂你的潜台词。
你日常对话的 Codex，又不止这一个模型。把它拆开看，是一整圈运行时套着一个模型。2026 年有一篇源码解剖研究，把十一个生产级编码智能体的代码全部翻开，把模型以外的这圈运行时统称为 harness——这个词 2026 年初已在社区流行——并写下广为流传的公式：编码智能体等于模型加 harness。harness 就是模型以外的一切，包括执行循环、工具调用、上下文管理、安全与权限、编排。你打的字、它读的文件、它跑命令后看到的输出，都要经过 harness 组织，最后才变成模型眼前的那串文字。Harness Engineering
下面这张图，就是从那十一个系统里归纳出来的通用解剖图：
图注：黄色虚线框里是 harness 的七个子系统：居中的 Agent Loop 是心脏，Memory & Context 管上下文，Tool & Action System 管动手，Safety & Permissions 管放行，外圈还有模型接入、扩展与编排。左侧的 Interface Layer 是你和它对话的入口，与 Agent Loop 双向连通。图上没有标注任何厂商，这是一张通用解剖结构图。Harness Engineering
注意信息是怎么流的：你的需求从左侧进入，被组织进 Memory & Context，再由 Agent Loop 驱动，一步步变成工具调用和代码改动。整张图里没有任何一个子系统的职责是“替用户脑补没写的要求”。上下文是它唯一的输入通道，通道里没有的东西，对整套系统都不存在。
harness 里最核心的那个循环，长什么样？所有编码智能体的循环都是同一种基本形状：读上下文、采取行动、观察反馈、再循环。区别只在于怎么组织：
图注：三种主流的循环组织方式。(a) 迭代式：Prompt → LLM → 执行 → 观察，四步回环，多数系统长这样；(b) 反思增强：改完代码先跑 lint 和测试，把结果喂回循环再决定下一步；(c) 协调者叠加：一个 Coordinator 把任务拆给多个 Worker，再汇总结果。图里只讲范式，没有标注任何厂商。Harness Engineering
留意 (b)：它已经把“跑测试、看反馈”放进了循环，这是后面第五章“验证回路”的雏形。模型本身只会补全，是 harness 这个循环给了它“写完能自己检查一下”的能力。但循环里每一个环节读到的信息，仍然都来自你写进上下文的那点文字。
这章最后想让你带走一个词：愿望与机制的差别。那篇源码研究有个耐人寻味的观察：好几个互不相关的 harness，系统提示词里都写着“不要过度交付”“不要改你没读过的代码”这类话。大家用修辞预言了同一个失败模式：模型会在需求没写清楚的地方自由发挥。研究者同时提醒，prompt 里的文字只是行为愿望，不是机制。想让 Codex 别自由发挥，靠的不是在提示词里求它自觉，而是把话写进上下文，让它没有自由发挥的余地。Harness Engineering
机制说到这里，代价还没算。需求没写清，到底会让你多付多少返工的学费？
2 需求没说全会怎样：晚一步才说，代价是约两倍的返工
上一章的结论听起来像理论推演。会不会实际上没那么严重？毕竟它跑起来不对，我贴回去它就改了。要回答“严重到什么程度”，得看真实会话数据。2026 年有一项研究，专门去挖真实世界的 coding-agent 会话语料，数据集叫 SWE-chat，把真实的人机对话、git 提交、行级的人与 agent 归属连在一起。研究者想回答一个问题：需求在实现开始之后才浮出水面，要付多少代价？ReqRework
他们定义了一类现象叫“晚露需求”：用户在实现开始之后，才提出先前没说过的新要求，改动目标、约束或验收标准。在筛选出的 402 条至少携带一次这类事件的会话里，出现了三个扎眼的数字。
其一，54% 的事件发生在会话中点之后。需求不是开工前一次说清的，一半以上拖到实现后半程还在往外冒。其二，每条新需求到达之后，先前 agent 写的代码被删除或替换的量，大约是匹配的普通编辑的两倍。其三，被删掉的往往不是半成品：71% 的事件主要打在已经“定型”的代码上，这些代码在被删之前，中位活过了 6 次编辑。
这里必须带两个限定：这是 SWE-chat 单语料上的观察，换语料未必同样成立；而且“两倍”是时间上的关联，论文作者明确声明这不是已证明的因果。但作为现象的度量，它比“我觉得它老返工”可靠得多。研究者还顺带发现，agent 的习惯是“先编辑、等用户纠正”，所以你的新需求一冒出来，撞上的往往是一个已经写好的实现，成本当场以覆盖代码的形式在会话里付清。你看到的是“它又改了一遍”，本质是返工。
下面这张图说明这些结论不是访谈感受，而是按可复现的流程测出来的：
图注：研究设计分两部分。左半是语料挖掘：从真实人机会话里识别需求变更事件，重建仓库中间状态，重放后测量先前代码被无效化的量。右半是两个受控实验，检验“提前警告需求”这类干预的效果。具体百分比都在正文里，这张图只说明结论是怎么测出来的。ReqRework
为什么需求会漏？回到第 1 章的机制，把“一次写不对”拆成三个洞，每个洞配一句它的内心戏。
第一个洞，最终目标没说。你没告诉它“要什么”，它就挑一个统计上最顺的目标去实现。它不知道你要导出 CSV 还是 Excel 工作簿，只知道“导出”两个字后面最常见跟的是什么，于是它写出了最像的“导出”，而不是你要的那个导出。
第二个洞，隐含假设没说。用什么编码、日志写到哪、要不要兼容旧版本、失败时静默还是报错，这些你觉得“当然如此”的默认值，它一条都不知道，只能按训练分布猜一个。人跟人之间能靠“常识”补齐的默契，在它这里全部不存在。
第三个洞，边界与错误处理没说。空输入、超长行、非法格式、网络中断，这些“异常但会发生”的情况，它只能挑一种“最像”的处理方式。而你的系统对每一种异常可能都有明确预期，只是没写出来。
三个洞合起来，就是第 1 章那条推论的现实版：没写清，它就自由发挥；自由发挥，就会产生返工。机制给了原因，数据给了账单。所以下面两章要给的处方，目标优先和边界清单，不是锦上添花的技巧，是止血。
账单看完了。第一步该先钉死什么？答案呼之欲出：先讲“要什么”，再谈“怎么做”。
3 先讲“要什么”，再讲“怎么做”：目标与验收标准必须放在最前面
回到你写 prompt 的习惯。大多数人下意识先描述做法：帮我写个函数，遍历这个数组，把结果拼成字符串。如果你也这么写，第 1 章的机制会告诉你为什么经常翻车：模型是顺着你描述的做法往下续写的，方案细节说得越多，它越容易被“怎么做”带走，真正要达成的“要什么”反而成了背景板。
OpenAI 官方的 Codex 最佳实践给了一个反过来的结构，推荐在需求里默认包含四要素。Goal（目标）：你要改变或构建什么。Context（上下文）：哪些文件、文档、示例或报错跟这个任务相关，可以用 @ 直接点名。Constraints（约束）：要遵循什么标准、架构、安全要求或工程约定。Done when（完成判据）：任务完成之前必须为真的事，比如测试通过、行为改变、某个 bug 不再复现。官方原话是，这套结构能帮 Codex 保持范围、少做假设、产出更容易 review 的成果。Codex Best Practices
把四要素画出来，它是这样一块一块摞起来的：
四个要素里，最值得你停下来的叫 Done when。它是整段需求里唯一能当“尺子”用的东西。模型自己判断不了“好代码”长什么样，它只知道“像的代码”长什么样。你必须把尺子递给它：跑通哪个测试算完成，哪个行为必须改变，哪个 bug 不再复现就算赢。尺子越具体，它自查的时候越不需要猜。顺手补一个通用注脚：OpenAI 的通用 agent 设计指南把 agent 拆成模型、工具、指令三个组件，断言清晰的指令减少歧义、直接决定决策质量，四要素结构就是这条原则在 Codex 上的落地形态。OpenAI Agents Guide
这里有一个相邻方案的差别，值得单独拎出来。你可能想：那我在需求里写一句“先给我讲一遍你的计划，再开始写码”，不也能让它想清楚吗？官方不建议这么做，而且给了机制层面的理由：这类“先讲计划”的 prompt 会让模型在完成整个任务之前戛然停止，它把“生成计划”当成了回合的终点。Codex 的官方 prompting 指南明确把“删掉这类 prompt”列为提升性能的主要杠杆。Codex Prompting
想让 Codex 先想清楚再动手，正确姿势是结构性机制，而不是文字请求。Codex 有 plan mode，用 /plan 或 Shift+Tab 打开：它先以只读方式收集上下文、问你澄清问题、形成计划，确认之后才开始写码。如果你自己也说不清需求，就让 Codex 反过来 interview 你，官方文档的描述是让它先提问、挑战你的假设，把模糊的想法在写码之前变具体。一个是让系统进入“只规划、不写码”的结构状态，一个只是在提示词里请它嘴上念一遍计划，两者看着像，机制上完全不同。
但目标再清楚，也只是把“要什么”钉死了。真正让你心里发虚的是另一半：那些异常但会发生的东西。下一章处理你最怕漏的那一块，边界与错误处理。
4 边界和错误处理怎么才能不漏：把“异常但会发生”逐条写成需求
如果说目标问题靠“想清楚”就能解决，边界问题则相反：靠细心永远堵不完，靠清单才能不漏。
先给你一套能直接照抄的边界写法。长期跟编码智能体打交道的工程师 Addy Osmani，在 2026 年初写了一篇流传很广的博客，讲怎么给 agent 写 spec。他把“该做什么”分成三档，比平铺的 don't 清单好用得多：
| 档位 | 含义 | 例子（来自博客原文） |
|---|---|---|
| Always do | 不用问，直接做 | 提交前永远先跑测试；出错永远记进监控服务 |
| Ask first | 影响大，先问人 | 改数据库 schema 前先问；加新依赖前先问；改 CI/CD 配置前先问 |
| Never do | 硬停，绝不做 | 绝不提交 secrets 或 API key；绝不改 node_modules 或 vendor 目录；删任何失败测试都要先经批准 |
写这三档的时候，心里过一遍你项目里最怕它自作主张的动作：哪些该默认执行，哪些要它停下来问你，哪些要它宁可什么都不做。据博客转述的 GitHub 分析，几千份 agent 配置文件里最常见的一条有效约束，就是 Never commit secrets。Osmani Spec
边界清单具体该列哪些内容？有四类输入最常被漏，也最容易让模型自由发挥。空输入：它不知道空数组该返回空数组还是抛异常，只能猜一个最像的，很可能跟你系统里其他函数不一致。超长：字符串长到几万字符要不要截断、在哪截，它不会替你决定。非法格式：日期传成了 2026-13-99，它报错还是静默返回 null？失败路径与并发：文件写不进去、请求超时、两个请求同时改同一行，它只会按最常见的套路处理。
把这几类写进需求，措辞有讲究。与其写“要正确处理空输入”，不如写一句具体的：输入 [] 时应返回 [] 而不是抛错。这就是本章最重要的技巧，规格即例子。一两组“输入到期望输出”的对应，比十句抽象描述更能钉死行为，因为它相当于给模型内嵌了一条最小测试：模型补全完代码，拿你的例子一对，立刻知道对不对。再补一个反直觉的点：你还要显式写出“不做什么”，也就是 out-of-scope。模型默认顺着你的话往下做，你不拦着，它会顺手多做一步，重构你没让改的模块、加一个你没要的依赖、删掉“看起来没用”的旧代码。scope 说得越窄，它越不容易越界。
代码任务为什么对含糊这么零容忍？2024 年提出 flow engineering 的那篇 AlphaCodium 论文点破了原因：生成代码必须和目标语言的语法精确匹配，必须能识别正常路径和边界情况，还要注意需求说明里大量的小细节。自然语言任务里可以含糊带过的地方，代码任务里一含糊就错，语法差一个括号都跑不起来。这给下一章埋了个伏笔：既然单次补全必然有漏网之鱼，写对就不能只靠开头那一段话。AlphaCodium
需求写到这份上，已经比大多数人都仔细了。可模型的一次补全仍然可能跑偏。它还是写错了，怎么办？
5 它还是写错了怎么办：别再重述需求，给它能跑的 check 与证据
先承认一个事实：写得再好的需求，也只是提高了一次补全的正确概率，不能保证一次写对。真正让“写对”变可靠的，是把单次赌注换成一条能自我修正的回路。这条路有名字，叫 flow engineering（流程工程）。它的提出点是 2024 年 CodiumAI 的 AlphaCodium 论文，标题就叫“从提示工程到流程工程”。论文在竞争编程数据集 CodeContests 上做了实验：同样用当时的 GPT-4，把题目交给精心设计的单次 prompt，pass@5（生成五份代码里至少一份跑通测试的概率）是 19%；改成一套多阶段流程之后，同一个模型涨到 44%。注意限定：这是 2024 年、CodeContests 验证集上的数字，不代表现在的模型水平。但它证明的机制不过时：把写对从碰运气变成可收敛，靠的是流程，不是咒语。AlphaCodium
那套流程长这样：
图注：AlphaCodium 的两阶段流程。上半段是线性的预处理：反思问题本身、推理公开测试在考什么、生成几个候选解法并排序、再额外生成一批 AI 测试。下半段进入代码迭代环：生成初始代码，先对着公开测试修，再对着 AI 生成的测试修，直到通过。AlphaCodium
注意流程里最关键的一步：额外生成 AI 测试。为什么写测试比写完整解法更重要？因为对模型来说，生成测试只需要理解问题，不需要完整解出问题，容易得多。先让模型把边界“翻译”成一批它能自己跑的测试，再用这些测试去收敛代码，等于把边界写进了流程，而不是写进一句话。这也回答了为什么不能只跑题目自带的公开测试：
图注：三种做法的对比。单次直接 prompt 常常解不出来；只对着公开测试迭代能稳定改善，但公开测试覆盖不到的地方会留下盲区；完整流程在预处理阶段额外生成 AI 测试去逼近边界，收敛得最彻底。图里只有趋势示意，具体百分比在正文。AlphaCodium
这套思想早就产品化了，而且 OpenAI 和 Anthropic 两家官方文档的说法出奇一致。OpenAI 的 Codex 最佳实践建议，别只让 Codex 改代码，让它自己写测试、跑正确的测试套件、查 lint 和类型、确认最终行为、再 review 一遍 diff。原话是：Codex can do this loop for you, but only if it knows what good looks like。只有当它知道“好”长什么样，它才能自己跑完这条验证回路；而 good 的定义，来自你的需求或 AGENTS.md。Codex Best Practices
Anthropic 的 Claude Code 文档把同一件事说得更直白：Claude 会在工作“看起来做完了”的时候停手。没有可运行的 check 时，looks done 是它唯一的信号，于是你就成了那条验证回路。反过来，只要你给它一个能跑出 pass/fail 的东西，测试套件、构建退出码、lint、把输出和 fixture 比对的脚本，循环就自动闭合：它干活、跑 check、读结果、修、再跑，直到通过。这里引的是 Claude Code 的实践，用来做跨产品印证，不是 Codex 的功能清单。但两家官方结论一致，说明这是通用规律，不是某一家的偏好。Claude Code
回路会跑，可模型仍然可能修错方向。这时候，你的反馈质量决定收敛速度。Anthropic 文档给的规则只有一条：给证据，不要给断言。贴出报错输出、告诉它你跑了哪条命令、返回了什么、实际行为和期望差在哪，而不是说“不对，重新来”。为什么有效？因为审证据比重跑一遍验证快，而且对你没盯着的后台会话同样成立。对比一下就明白：
| 无效反馈 | 有效反馈 |
|---|---|
| “还是不对，你再想想” | “npm test 里 test-export 失败：期望输出带 UTF-8 BOM，实际没有。请修正并跑通该测试。” |
| “功能没写对” | “空表时导出抛了 TypeError，期望是只输出表头行。附上堆栈，请修复。” |
还有一条上下文纪律：纠错两轮还在原地打转，就别再硬磨。开新会话清空上下文，把这一轮学到的写进更精准的初始需求，重开。干净会话加更好的 prompt，几乎总是赢过带着积压失败的冗长会话，因为上下文是最稀缺的资源。
到这里，机制、结构、清单、回路都齐了。最后一章，把它们合成一次完整改造给你看。
6 从一句模糊想法到一次写对：一次完整改造，和一张你带得走的检查清单
用一个你能立刻代入的例子收尾。假设你打开 Codex，打出这句话：
帮我写个导出功能。
它大概率会写出一个“看起来对”的导出：一个函数，把数据拼成 CSV，完事。然后你导入 Excel，中文乱码。这正是第 1 章开头那个场景的完整版。下面我们把这句话按前几章的方法改造一遍。这是一个教学用的合成案例，里面的每一个要素都来自官方文档和上文讲的方法，没有编造任何统计数字。
| 要素 | 写进需求的话 | 对应原则 |
|---|---|---|
| Goal | 给数据表格加一个导出功能：导出成 CSV，用 Excel 打开中文不乱码 | 第 3 章：先说要什么 |
| Context | 数据在 @src/data 的 models.ts；参考 @src/utils/export.ts 里现成的工具函数；构建方式见 README | 第 3 章：点名上下文 |
| Constraints | 输出 UTF-8 with BOM；列顺序与表头一致；不新增第三方依赖；不改动现有接口 | 第 3 章约束 + 第 4 章 out-of-scope |
| Done when | npm test 通过；手动用例：用 Excel 打开导出文件，中文无乱码 | 第 3 章：验收尺子 |
| 边界清单 | 空表时只导出表头；字段含逗号、引号、换行时正确转义；超长文本不截断；目录不可写时报可读错误而不是静默成功 | 第 4 章：异常但会发生 |
| 输入到输出示例 | 输入 [{"name":"张三","city":"北京"}]，期望文件以 UTF-8 BOM 开头，内容含 name,city 表头与转义正确的数据行 | 第 4 章：规格即例子 |
| 验证命令 | 实现后运行 npm test 与 node scripts/verify-export.mjs，后者检查 BOM 与转义 | 第 5 章：可运行的 check |
逐行看这张表，每一格都是前面某章原则的落点：Goal 和 Done when 是把“尺子”递过去，边界清单和输入输出示例是把“怕漏”变成“不漏”，验证命令是给循环一个能跑出 pass/fail 的判据。这不是什么更高明的 prompt 模板，而是同一套方法在不同侧面的展开。
需求发出去之后，别干等。让它跑 check、读证据；真没写对，就贴出报错和期望行为，纠一轮。等它交活时，再补一句自验证句式，这是 Osmani 博客里给的自查咒语：实现后对照上面的需求逐条确认，列出任何未满足的项。Osmani Spec
这一步把“看起来做完了”换成了“对照清单逐条核对完了”，模型自己就成了第一道验收。
这次写对之后，怎么让它变成下次也写对？把成果沉淀成仓库级文件。Codex 官方文档给的答案是 AGENTS.md：一份自动加载进上下文的 open-format README，写给 agent 看。里面写仓库布局和关键目录、怎么运行项目、build/test/lint 命令、工程约定、do-not 规则，以及最重要的一条：what done means and how to verify work，也就是这个仓库里“什么算完成、怎么验证”。作用范围分三层：全局的个人默认、仓库级的共享标准、子目录的局部规则，离当前目录越近的越优先。Codex CLI 的 /init 能先生成草稿再按团队改写。官方还给了条实操纪律：当 Codex 两次犯同一个错，让它复盘一次，把结论写进 AGENTS.md。于是刚才那段需求里的编码约定、转义规则、验证命令，就从一次对话变成了仓库的默认行为。Codex Best Practices
再往上走一步，把“一次写对”升级成团队的“每次都写对”，靠的是把需求本身当作品质管理的对象。社区和学界在这点上汇合了。Osmani 那篇博客的主张是：spec 应该是你和 AI 共建的第一个产物、一份持续维护的单一事实源，提交进 git，随代码一起演进，更新了 spec 要显式告诉 agent“我把 spec 改成了这样”。学术界给它补了框架：2026 年有一篇把 spec-driven development 形式化的工作，主张 spec 是让契约、协调、信任在 agentic 软件工程里涌现的基质。需要说明的是，那篇论文把自己定位为概念框架，没有实证数据，它描述的是机制和方向，不是已验证的效果。SpecDriven
论文里那张传导链图，正好替这整篇教程收个尾：
图注：以 spec 为基质的传导链：spec 让契约、协调与信任得以涌现。没有 spec 时，协调与信任只能从代码和对话历史里重建，规模一大就撑不住；有 spec 时，产物对得上契约的证据可审计，信任才可扩展。图中是概念传导关系，不含流程步骤和量化指标。SpecDriven
最后，把整篇教程压缩成一张六步检查清单。下次开工之前，照着走一遍：
| 步骤 | 问自己 | 对应章节 |
|---|---|---|
| 1 目标 | 我要它改变或构建什么？一句话写清楚 | 第 3 章 |
| 2 验收 | 什么算完成？哪个测试通过、哪个 bug 不再复现？ | 第 3 章 Done when |
| 3 边界 | 空输入、超长、非法格式、失败路径各自该怎样？逐条列出 | 第 4 章 |
| 4 示例 | 给一组输入到期望输出，钉死行为 | 第 4 章 |
| 5 验证命令 | 告诉它怎么跑测试、怎么看结果 | 第 5 章 |
| 6 自查句 | 收尾加一句：实现后对照需求逐条确认，列出未满足项 | 第 6 章 |
把需求说清楚不是天赋，是流程。回到标题那个问题：需求到底该说得多清楚？答案很简单，清楚到它不需要猜。目标、验收、边界、示例、验证命令，这五样一旦都出现在它看得见的上下文里，“一次写对”就从运气变成了大概率事件；再用 AGENTS.md 和 spec 把它们固化成默认，“这次写对”才真正变成“每次都写对”。
参考文献
本专题引用的核心资料如下，建议深入学习时阅读原文：
- Best practices – Codex（OpenAI Developers 官方文档） — https://developers.openai.com/codex/learn/best-practices
- Codex Prompting Guide（OpenAI Cookbook） — https://developers.openai.com/cookbook/examples/gpt-5/codex_prompting_guide
- Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents（arXiv:2609.00006） — https://arxiv.org/abs/2609.00006
- Spec-Driven Development for Agentic Software Engineering（arXiv:2609.00252） — https://arxiv.org/abs/2609.00252
- Requirements After the First Edit: Mining Late Requirement Emergence and Rework in Real-World Coding-Agent Sessions（arXiv:2609.03028） — https://arxiv.org/abs/2609.03028
- A Practical Guide to Building Agents（OpenAI） — https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf
- Best practices for Claude Code（Anthropic） — https://code.claude.com/docs/en/best-practices.md
- Code Generation with AlphaCodium: From Prompt Engineering to Flow Engineering（arXiv:2401.08500） — https://arxiv.org/abs/2401.08500
- Language Models are Few-Shot Learners（arXiv:2005.14165） — https://arxiv.org/abs/2005.14165
- How to write a good spec for AI agents（Addy Osmani） — https://addyosmani.com/blog/good-spec/