共享工作区里让 Codex 改代码：先护住别人的改动

教程定位

这篇教程解决什么问题

多人共用一个分支、一个本地工作区，或者一个远程开发环境时，最危险的不是 Codex 写错一行代码，而是它把不属于自己的改动也“整理”了。你只是让它修一个表单校验，它看到旁边文件有格式不一致，就顺手格式化；你只是让它补一个接口字段，它发现测试失败，就把别人正在改的测试快照更新掉；你让它“恢复到能跑”，它可能把同事未提交的半成品改动回退。结果是任务看起来完成了，协作现场却变乱了：谁改了什么说不清，评审 diff 混在一起，甚至把别人还没提交的工作覆盖了。

这篇教程讲的是共享工作区里的 Codex 编辑边界。它不讨论复杂的 Git 工作流，也不要求每个人都立刻切干净分支。现实里很多团队会在同一个共享分支上赶修复，或者在远程机器上让多个 Agent 分头生成文件。此时最重要的纪律是：Codex 在动手前必须先识别当前工作区已有改动，判断哪些可能属于用户或其他同事；它只能编辑本轮负责的目标文件；如果发现需要触碰边界外文件，或者目标文件里已经有别人未完成的改动，必须停下来确认，而不是自行合并、自行回退、自行“清理现场”。

本文的场景是一个真实开发团队常见的小混乱：本地工作区已经有未提交修改，其中一部分是同事刚刚改的页面，一部分是你自己上午做的配置调整，还有一部分是别的 Agent 同时写出来的草稿。你现在要让 Codex 修改一个明确的文件，例如 `src/features/orders/OrderExportButton.tsx` 或一篇官网教程草稿。正确做法不是直接说“帮我改一下”，而是先让 Codex 输出“改动来源判断”和“只改清单”，再允许它动手。

读完这篇，你会得到一套可以复制的协作编辑守则：开始前看状态、看目标文件 diff、确认本轮唯一文件、写明不可触碰范围、编辑时只用局部补丁、改完只检查自己的差异、遇到冲突停下问人。它的价值很朴素：让 Codex 像一个懂规矩的协作者，而不是一个看见脏工作区就急着打扫的工具。

使用场景

什么情况下最适合用这一套

你是在共享分支上工作的开发者。团队今天在赶一个版本，大家都在同一个功能分支上提交小修。你本地工作区并不干净：订单模块里有同事刚改过的导出逻辑，后台配置里有你自己临时调试留下的环境变量示例，测试目录里还有另一个 Agent 正在补快照。现在产品又来一个小需求：把订单详情页的一个按钮文案改掉，或者给官网补一篇 Codex 教程。

如果是你自己手改，你大概会先看一眼当前改动，确认哪些文件不能碰。但换成 Codex，很容易因为一句提示词写得太宽，让它把整个工作区都当成自己的编辑范围。比如你说“修好这个问题并确保测试通过”，它可能会读到测试失败，然后修改测试文件；你说“把相关代码整理一下”，它可能会格式化共享组件；你说“如果有冲突就处理掉”，它可能会把别人未提交的改动覆盖成它认为正确的版本。

共享工作区里，Codex 需要先回答三个问题：

这三个问题没回答清楚之前，不应该让它进入写代码阶段。因为在共享工作区中，“能修改”不等于“该修改”。某个文件在技术上可写，不代表它属于当前任务；某个测试失败，不代表 Codex 可以改测试；某个 diff 看起来不优雅，不代表它可以顺手重构。

一个典型例子是：你让 Codex 只改 `content/website-articles/1067-remediation/article-drafts/codex-protect-user-changes-while-editing.md` 这篇文章。目录里还有一百多篇其他稿件，有些刚被别的 Agent 生成，有些还没被人工审。Codex 如果为了“统一风格”去改旁边文章，就破坏了协作边界。它能做的是读取同类文章来参考结构，随后只创建或修改自己负责的这一个文件。即使它发现其他文章 front matter 不一致，也只能在总结里提醒，不能动手修。

再看代码场景。你负责改 `OrderExportButton.tsx`，但 `OrderListPage.tsx` 已经有同事未提交的改动。Codex 读页面文件是可以的，因为它需要理解按钮如何被调用；但如果它为了接线更方便去改页面文件，就必须先停下。停下不是低效，而是保护协作现场。你们之后可以决定：是扩大本轮范围、让同事先提交、还是把任务拆开。真正危险的是 AI 没有停，直接替大家决定。

这套方法适合几类场景：多人共用开发机、多人在同一远程 workspace 改文件、一个人同时开多个 Codex 会话、主分支或共享分支上存在未提交修改、任务要求只改一个目标文件、项目里有生成文件或台账文件不能随便碰。只要出现这些条件，第一步都应该是“识别改动边界”，不是“开始写”。

1. 当前工作区里有哪些已有改动？
2. 这些改动是否可能不是本轮任务产生的？
3. 本轮任务允许它修改哪些文件，哪些文件只能读取，哪些文件完全不能碰？

材料准备

开始前先把材料和边界备齐

开始前，你要准备四类信息。它们不复杂，但必须明确。

第一类是当前工作区状态。你不一定要把完整输出都贴给 Codex，但至少要让它知道哪些文件已经被修改、哪些是未跟踪文件、目标文件是否已存在、目标文件当前有没有内容。共享工作区里，未提交修改默认都应该被当成“可能属于别人或上一轮任务”，不能被 Codex 视为可随意整理的垃圾。

第二类是本轮任务范围。范围要写成可执行边界，不要只写业务目标。比如“只修改 `src/features/orders/OrderExportButton.tsx`，可以读取 `OrderListPage.tsx` 和相关测试，但不能修改它们”；或者“只创建这篇 Markdown 文件，不更新索引、不改台账、不跑发布”。范围越清楚，Codex 越不容易把“为了完成任务”解释成“可以动所有相关文件”。

第三类是团队协作约定。每个团队的约定不同：有人要求 AI 不能碰生成文件，有人要求测试快照必须人工更新，有人要求遇到脏工作区先暂停，有人允许 AI 在明确目标文件内覆盖旧内容。你要把这些约定写进提示词，而不是指望 Codex 自动知道。尤其要写明：不要回退、删除、重写别人文件；不要用一键恢复命令；不要把不属于本轮的 diff 格式化；发现边界外问题只报告，不修复。

第四类是目标文件的状态。如果目标文件已经存在，先让 Codex 读它，再判断是续写、局部修改还是重写。如果目标文件不存在，可以创建；如果目录不存在，要先确认是否允许创建目录。这个细节在共享仓库中很重要。因为“创建目录”有时也会影响别人的自动化或生成流程，不能默认为无害。

你可以把准备材料整理成这样：

这段准备材料的重点不是“限制 AI 的能力”，而是让它知道协作现场的责任归属。Codex 可以很擅长找问题、改代码、补文档，但它不应该替团队决定谁的改动可以被覆盖。

当前情况：
- 本地工作区可能已有未提交修改。
- 这些修改可能来自我、同事或其他 Agent。
- 本轮只允许创建/修改一个目标文件。

目标文件：
- content/website-articles/1067-remediation/article-drafts/codex-protect-user-changes-while-editing.md

允许：
- 读取项目内 workflow 和同类文章作为参考。
- 创建或修改目标文件。
- 只检查目标文件是否满足要求。

禁止：
- 不修改其他文章。
- 不更新索引、台账、构建配置或发布记录。
- 不回退任何已有改动。
- 不删除未跟踪文件。
- 不运行会自动格式化全仓库的命令。
- 如果发现必须改目标文件之外的内容，先停下来说明原因，等待确认。

实操流程

按这套步骤把工作跑起来

第一步，让 Codex 先看当前改动，而不是直接编辑。它可以查看工作区状态、目标文件是否存在、目标文件附近是否有同类样例。这个动作的目的不是让它清理工作区，而是建立“现场地图”：哪些文件已经有改动，哪些文件是本轮目标，哪些文件只读参考。

第二步，让 Codex 明确改动来源判断。严格说，它无法百分百知道某个未提交 diff 来自谁，但它可以按保守原则处理：凡不是本轮刚刚产生的，都当作用户或同事改动；凡在目标文件之外的，都默认不属于本轮；凡看起来像生成结果、快照、台账、配置、锁文件的，都需要额外谨慎。这里的关键是“无法确认就保护”，不要“无法确认就覆盖”。

第三步，输出本轮编辑边界。边界应该写到文件级别，最好也写到行为级别。例如：

第四步，要求 Codex 在编辑前复述“不会做什么”。这听起来有点啰嗦，但很有效。让它明确说：不会回退别人改动，不会删除未跟踪文件，不会整理无关 diff，不会把测试失败当成自动修改其他文件的理由，不会使用破坏性恢复命令。共享工作区里，负面边界往往比正面任务更重要。

第五步，开始编辑时只使用局部补丁。不要让 Codex 通过全仓库格式化、批量替换或“重新生成整个目录”来完成一个小任务。即使目标文件很长，也应该尽量创建或修改这一份文件。如果目标文件已有内容，优先用局部替换；如果必须重写，先说明为什么，并确认这份文件确实属于本轮责任范围。

第六步，编辑过程中如果发现目标文件外的问题，只记录，不修。比如 Codex 读到某个调用方类型不匹配，或者发现另一个模块的文案也不统一，应该先写成“边界外发现”。除非你明确扩大范围，否则它不能顺手修改。很多协作事故就是从“我顺手修一下”开始的。

第七步，改完后只检查自己的文件和自己的差异。检查可以包括：目标文件是否存在、front matter 是否完整、必需章节是否齐全、字数是否达标、代码块是否存在。对于代码任务，则可以运行与目标文件相关的局部测试。但如果检查工具会自动改全仓库，或者测试失败来自别人文件，要停下说明，不要为了让检查绿而修改边界外内容。

第八步，交付时说明“只动了什么”和“没有动什么”。共享工作区里的交付说明不只是结果汇报，也是一份协作声明。你可以写：“本次只创建目标 Markdown 文件；读取了官网写作工作流和同类稿件作为参考；未修改索引、台账、其他文章或发布配置；未执行外部发布动作。”这比单纯说“完成了”更有安全感。

第九步，如果目标文件在你编辑期间被别人改了，停止确认。不要让 Codex 自动合并两份内容，除非任务已经明确允许它解决冲突。正确行为是告诉用户：目标文件出现非本轮改动，需要确认是保留对方版本、在对方版本上追加，还是暂停等待对方完成。共享环境里，冲突不是 AI 展示聪明的舞台，而是人类协作者需要重新分配边界的信号。

第十步，把这套规则写进后续提示词。一次任务里讲清楚当然有用，但更好的做法是形成固定模板。以后只要你让 Codex 在脏工作区里改东西，都先贴“协作编辑守则”。这能大幅减少意外覆盖和无关 diff。

• 可修改：`src/features/orders/OrderExportButton.tsx`。
• 可读取：`src/features/orders/OrderListPage.tsx`、`src/features/orders/orderExport.ts`、相关类型文件。
• 不可修改：订单列表页面、共享表格组件、测试快照、配置文件、锁文件。
• 触发暂停：需要改边界外文件、目标文件有别人正在写的半成品、测试失败来自无关文件、发现大面积格式化差异。

输入示例

可以直接参考的输入材料

下面是一份真实共享工作区场景的输入样例。它不是让 Codex 立刻写代码，而是先让它识别边界。

如果任务是写内容稿，也可以使用同样结构：

这两个样例有一个共同点：它们把“文件边界”写得比“业务目标”还清楚。因为共享工作区里的主要风险不是 Codex 不知道怎么改，而是它太愿意帮你把周边也一起改。

你现在在一个共享工作区里工作。这里可能已经有我、同事或其他 Agent 的未提交修改。

任务：
修复订单导出按钮的文案。导出进行中时，按钮应该显示“正在导出”，而不是“导出中...”。本轮只处理这个按钮文案，不做其他重构。

本轮唯一允许修改的文件：
src/features/orders/OrderExportButton.tsx

允许读取：
- src/features/orders/OrderListPage.tsx
- src/features/orders/orderExport.ts
- src/features/orders/__tests__/OrderExportButton.test.tsx

禁止修改：
- 除唯一目标文件之外的任何文件
- 共享 Button 组件
- 订单列表页面
- 测试快照
- 配置文件、锁文件、生成文件

协作要求：
1. 开始前先查看当前工作区状态和目标文件状态。
2. 把已有未提交修改默认视为用户或同事改动，不要回退、删除、格式化或重写。
3. 只编辑目标文件。如果发现必须改其他文件才能完成，先停止并说明原因。
4. 如果测试失败来自目标文件之外，先报告，不要修改那些文件。
5. 完成后只汇报目标文件的变化和检查结果。

请先输出：
- 当前工作区风险判断
- 本轮可修改/可读取/不可修改清单
- 你会在什么情况下停下来确认
确认后再开始改目标文件。

你是官网文章单篇写作 Agent。项目里可能有其他 Agent 同时写不同文件。

唯一负责文件：
content/website-articles/1067-remediation/article-drafts/codex-protect-user-changes-while-editing.md

允许：
- 读取 workflows/website-update.md
- 读取同目录 Codex 类文章作为风格参考
- 创建或修改唯一负责文件

禁止：
- 不修改其他文章
- 不更新官网索引
- 不更新台账
- 不发布、不推送
- 不回退任何已有改动

写作要求：
[粘贴主题信息和章节要求]

请按共享工作区规则执行：先确认目标文件是否存在，再只创建/修改这个文件；如发现目标文件已有别人未完成内容，先停下确认。

提示词

可复制使用的提示词

下面是一段可以直接复制的通用提示词。适合任何“本地已经有未提交修改，但我只想让 Codex 改一个小范围”的场景。

如果你的团队经常在同一个分支上做紧急修复，可以把这段提示词放进任务模板。它不需要每次都很长，核心句子只有三句：先看改动；只改负责文件；冲突停下来确认。

你现在在共享工作区中协作。请把所有非本轮产生的未提交修改都视为用户、同事或其他 Agent 的改动，并保护它们。

本轮任务：
[写清楚任务目标]

唯一允许修改的文件或目录：
[写清楚路径。若只允许一个文件，就只写一个文件]

允许读取但不能修改：
[列出为了理解上下文可以读取的文件、目录或搜索范围]

明确禁止：
1. 不回退任何已有改动。
2. 不删除未跟踪文件。
3. 不重写、格式化、整理本轮范围外的文件。
4. 不使用会恢复、清理或覆盖工作区的命令。
5. 不把测试失败当成修改边界外文件的理由。
6. 不更新快照、锁文件、生成文件、台账或发布配置，除非它们明确列在允许修改范围内。

开始前请先做只读检查：
1. 查看当前工作区有哪些改动。
2. 查看目标文件是否存在，以及目标文件自身是否已有内容。
3. 输出可修改、可读取、不可修改清单。
4. 输出需要停下来确认的情况。

只有在边界清楚后再开始编辑。编辑时只对允许修改的文件做局部补丁。

如果出现以下情况，立即停止并向我确认：
- 必须修改允许范围外的文件才能继续。
- 目标文件中出现疑似别人正在编辑的内容。
- 检查失败来自范围外文件。
- 需要回退、删除、移动、重命名或批量格式化文件。
- 你无法判断某个改动是否属于本轮任务。

完成后请汇报：
- 实际修改的文件。
- 没有触碰的边界外文件。
- 本地检查结果。
- 是否发现需要人工处理的边界外问题。

输出样例

AI 应该输出到什么程度

下面是一份比较理想的 Codex 输出。它先建立边界，再进入执行，而不是直接改文件。

如果 Codex 接下来真的遇到边界外问题，理想输出应该是暂停，而不是继续：

这就是共享工作区里最值得培养的 Codex 行为：不是每个问题都抢着解决，而是在边界变化时把决定权交回来。

当前工作区风险判断：
我会先把当前未提交修改视为共享工作区中的既有改动。除非某个改动是本轮任务明确要求产生的，否则不会回退、删除、格式化或重写。

本轮可修改：
- src/features/orders/OrderExportButton.tsx

本轮可读取但不修改：
- src/features/orders/OrderListPage.tsx
- src/features/orders/orderExport.ts
- src/features/orders/__tests__/OrderExportButton.test.tsx

本轮不可修改：
- 共享 Button 组件
- 订单列表页面
- 测试快照
- 配置文件、锁文件、生成文件
- 其他已修改但不属于目标文件的内容

开始前检查：
- 目标文件存在，我会读取当前内容后做局部修改。
- 如果目标文件已有与导出文案无关的大段变更，我会先提醒你确认是否继续在此基础上修改。

我会停下来确认的情况：
1. 修改目标文件后发现类型或测试必须通过改其他文件才能解决。
2. 测试失败来自订单列表页面、共享组件或快照。
3. 目标文件在编辑期间出现新的外部改动。
4. 需要回退、删除、重命名或批量格式化文件。

计划：
1. 只在 OrderExportButton.tsx 中查找导出中状态的按钮文案。
2. 将该状态的显示文案从“导出中...”调整为“正在导出”。
3. 不修改共享 Button 默认文案，不修改测试快照。
4. 完成后只检查目标文件 diff，并报告是否需要你决定测试更新。

我需要暂停确认。

目标文件修改后，现有测试期望仍是“导出中...”，测试文件不在本轮允许修改范围内。为了让测试通过，需要更新：
src/features/orders/__tests__/OrderExportButton.test.tsx

这超出了本轮唯一允许修改文件。请确认下一步：
1. 允许我同时修改这个测试文件；
2. 保持只改目标文件，由你后续处理测试；
3. 暂停本任务。

人工验收

人要怎么检查和改到可用

Codex 按规则完成后，人还要做一遍轻量检查。这里的人工检查不是重新做全部工作，而是确认协作边界真的守住了。

第一项，看实际修改文件是否等于允许范围。如果任务说只改一个文件，那最终 diff 里就只能有这个文件。若出现其他文件，要先问：这是 Codex 改的，还是本来就有的？如果是本来就有的，交付说明里要说清楚“未触碰”；如果是 Codex 改的，要判断是否经过确认。没有确认就越界改了，应该把这次结果视为不合格。

第二项，看目标文件内部有没有覆盖别人内容。如果目标文件原本不存在，这项比较简单；如果原本存在，就要看 Codex 是局部追加、局部替换，还是整篇重写。整篇重写不一定错，但必须符合任务要求。比如用户明确要求“重写这篇草稿”可以；如果只是“补一个段落”，整篇重写就很危险。

第三项，看有没有“顺手修”。顺手修常见于格式化、导入排序、文案统一、测试快照更新、锁文件变化、生成文件变化。它们有时是合理动作，但在共享工作区里必须被授权。没有授权的顺手修，会让评审很难看，也容易覆盖别人正在做的工作。

第四项，看检查结果是否只针对本轮任务。比如写文章时，可以检查目标文件字数、front matter、必需标题、代码块；没必要跑全站发布。改一个组件时，可以跑相关测试；如果全量测试失败在别的模块，不要让 Codex 去修。人工要确认 Codex 没有为了“全绿”扩大范围。

第五项，把交付说明写成协作友好的格式。建议包括四句话：

如果你发现 Codex 已经越界，处理原则也要保守。不要让它自己“回滚全部”，因为这可能再次伤到别人改动。更稳妥的做法是先查看越界文件的 diff，确认哪些行是本轮造成的，再只撤销 Codex 自己的改动。如果无法分清，就停止，找相关同事或用户确认。

这也是为什么开始前的边界说明很重要。边界越清晰，事后越容易判断责任；边界模糊，出了问题连“什么算越界”都说不清。

本次实际修改：
- [目标文件路径]

本次未触碰：
- 其他已有改动
- 边界外文件
- 生成文件、锁文件、发布配置

本地检查：
- [通过了什么检查，或哪些检查未运行]

需要人工处理：
- [边界外发现、测试需要另开任务、需要确认的问题]

失败反例

这些失败反例要提前避开

反例 1：把脏工作区当成待清理现场。

错误提示词：

问题在于“有点乱”和“顺便整理”给了 Codex 很大的解释空间。它可能会格式化别人改过的文件，重排导入，更新快照，甚至删除未跟踪文件。共享工作区里，乱不等于可以清理；未提交不等于无主；测试没过不等于可以改所有文件。

更好的写法：

反例 2：把“相关文件”说得太宽。

错误提示词：

“相关文件”在代码库里可能非常多：页面、按钮组件、导出服务、权限判断、测试、文案、埋点、快照。Codex 一旦把范围理解成“所有相关都能动”，小需求就会变成大 diff。尤其在共享分支上，别人正在改的页面也可能被它纳入“相关”。

更好的写法：

反例 3：让 Codex 自动解决冲突。

错误提示词：

这句话在个人干净分支上有时方便，在共享工作区里很危险。冲突意味着两条工作线碰到了同一块内容，AI 不一定知道哪一条代表真实意图。它可能把同事未完成的逻辑删掉，也可能把两份不兼容的实现硬拼在一起。自动解决冲突看起来省时间，实际是在把协作决策藏进 diff。

更好的写法：

反例 4：为了测试通过而越界。

错误提示词：

在共享工作区中，这几乎等于把边界交出去了。测试失败可能来自别人的半成品，也可能来自环境问题，还可能来自旧快照。Codex 如果为了全量通过去修改测试、mock、配置或锁文件，本轮 diff 会变得不可审查。

更好的写法：

反例 5：让 AI 回退“看起来不对”的内容。

错误提示词：

“奇怪”是很主观的。别人正在写的半成品、临时调试日志、生成中的文章草稿，在 Codex 眼里都可能奇怪。但它们也许正是另一个人下一步要用的内容。共享工作区里，回退比新增更危险，因为它直接抹掉上下文。

更好的写法：

这些反例的共同问题，是把“完成当前目标”放在“保护协作边界”之前。正确顺序应该反过来：先保护边界，再完成目标。目标完成不了时停下来，并不是失败；悄悄越界完成，才是共享工作区里的失败。

这个仓库现在有点乱，你帮我把这个 bug 修好，顺便整理一下相关代码，让测试都通过。

当前工作区已有未提交修改，默认都不是本轮任务产生的。请不要整理、回退或删除任何已有改动。本轮只允许修改 src/features/orders/OrderExportButton.tsx。如果发现测试失败来自其他文件，先报告，不要修。

帮我改订单导出按钮，相关文件你看着办。

本轮唯一允许修改 src/features/orders/OrderExportButton.tsx。可以读取订单页面和导出服务理解上下文，但不能修改。若你判断必须改其他文件，请先停下来说明原因。

如果遇到冲突你自己处理，不用问我。

如果目标文件或相关文件出现冲突、外部改动或无法判断来源的 diff，请立即停止并说明选项，不要自行合并或回退。

改完后确保所有测试通过，需要改哪里就改哪里。

改完后可以运行与目标文件相关的检查。若失败来自允许修改范围外，请报告失败位置和原因，不要修改边界外文件。

如果发现有奇怪改动，帮我恢复正常。

如果发现目标范围外有异常或不完整改动，请只列出来，不要修改、删除或回退。由我确认是否另开任务处理。

主题边界

它和相邻主题的区别

这个主题和“小 bug 控范围”很像，但关注点不同。小 bug 控范围主要解决的是业务影响面：只修当前页面、当前状态、当前组件，不把一个文案 bug 改成全局重构。本文解决的是协作影响面：即使技术上相关，也不能碰不属于本轮的文件；即使看到别人的 diff 不顺眼，也不能回退或整理。前者是在问“代码行为会影响哪里”，后者是在问“这份改动归谁负责”。

它也和“生产风险先提问”不同。生产风险主题关注钱、权限、删除、审计、灰度等高风险业务逻辑，强调在事实不完整时不要实现。本文不一定涉及高风险业务，哪怕只写一篇文章、改一个按钮、补一个类型，也适用。只要工作区是共享的，保护别人改动就是第一优先级。

它还和“只改一个字段的小步流程”不同。单字段流程强调从接口、类型、映射到 UI 的最小技术路径；本文强调在这条路径外不能碰别人正在改的文件。如果新增字段必须改三个文件，就应该把三个文件明确列入允许范围；如果只允许改一个文件，那么发现第二个文件必须改时就要停止确认。

它和“读新仓库第一小时”也不同。读新仓库时，Codex 可以广泛搜索、建立地图、总结模块关系；但共享编辑时，搜索和读取不等于编辑许可。你可以让 Codex 读很多文件来理解上下文，却只允许它改一个文件。这个区分非常重要：读取范围可以宽，写入范围必须窄。

最后，它和 Git 教程也不同。本文不是教你如何 rebase、stash、cherry-pick 或解决复杂冲突。那些工具当然重要，但 AI 协作中的第一条规则更简单：不要假设脏工作区属于你。先看改动，限定文件，识别用户改动，冲突停下来确认，不要回退别人修改。做到这几句，Codex 在多人同时改仓库时就会可靠很多。