安装 Codex App，并打开第一个安全工作区

App 打开了，但它真的站在正确的目录里吗

第一次看到 Codex App 的输入框，很容易立刻把公司主仓库拖进去。问题是，你还没有证明登录、项目路径和写入边界都符合预期。

安装成功不是“界面出现”，而是你能用一组无风险证据说明它在哪里、看见了什么、没有碰什么。 这节课从一个只含两个虚构文件的目录开始。

这节课要交付什么

这不是一份只需要读完的功能介绍。你要在真实但可控的环境中留下一个可以复查的结果，并且能回答三个问题：Codex 看到了哪些事实，它实际做了哪些动作，你用什么独立证据确认结果成立。

最终结果是：一份能证明 App 登录成功、目录正确、只读检查有效的验收记录。开始前先创建一份简短记录，把当前环境、目标、禁止动作和验收方式写下来。后面的命令、截图和修改都回到这份记录，不靠聊天窗口里的“应该已经好了”判断完成。

先看官方边界

Codex App 适合围绕本地项目组织任务、观察改动和继续验证。安装入口、系统要求与账号可用性以官方 App 页面为准。首次体验不需要拿生产仓库冒险：一个只含 README 和示例文件的练习目录，已经足够证明登录、工作区和读取能力。

官方页面会随产品更新。教程引用的是当前可核对的能力与命令，不把界面位置、套餐权限或预览功能包装成永久承诺。你在自己的设备上看到不同按钮时，先核对官方页面和本机版本，再决定是否继续；不要用过期截图覆盖现场事实。

任务现场

你刚装好 App，侧边栏里还没有项目。桌面上同时有公司仓库、个人照片和一个空测试目录。真正的第一步不是随便点一个最近文件夹，而是创建 codex-first-workspace，只放 README.md 与 sample.txt，并把预期结构写进 README。这样即使选错动作，也没有真实业务后果。

先把现场写成四行：工作目录或项目、当前版本或输入、允许动作、完成证据。如果其中任何一行只能写“让 Codex 自己看”，说明上下文仍然不够具体。Codex 可以帮助检查，但不能替你决定哪些数据能上传、哪个生产动作已获授权，或一个异常是否可以忽略。

动手前准备

从官方页面获取安装包，完成系统正常的签名与权限检查后登录。新建练习目录，在 README 写明“这是只读安装验收；未经允许不要修改文件”。把目录的绝对路径和文件清单保存在 acceptance.md。公司设备若受 MDM 或代理限制，应按组织流程处理，不通过关闭安全软件绕过。

把练习放在可恢复的位置，保留原始输入，并记录开始时的状态。涉及代码时先看版本控制状态；涉及数据时先复制脱敏样例；涉及外部服务时先使用只读或草稿模式。准备工作看似慢，却能让失败变成一次可以解释和回退的实验。

第一步：只读建立基线

在 App 中明确选择 codex-first-workspace，先问：‘请只读检查当前目录，告诉我项目绝对路径、文件数量、README 中的限制；不要创建或修改任何文件。’随后在系统文件管理器独立核对路径和数量，并检查版本控制或文件时间戳没有变化。

这一阶段不要急着要求“直接修好”。先让 Codex 复述目标、列出它实际读取的来源，并指出还缺哪些证据。你要检查它有没有打开正确目录、有没有把搜索摘要当原文、有没有把旧日志误当当前状态。基线不可信，后面的修改越多，返工成本越高。

第二步：限制范围后执行

确认基线后，让 Codex 给 README 提出一条改进建议，但仍不执行。你批准后只修改 README，并要求交接实际变更。这个小动作验证了从只读到写入的权限变化，也让你第一次练习“建议不等于授权”。

执行指令应该同时包含目标、范围和停止条件。把“不要乱改”换成可观察边界，例如只允许修改两个文件、不安装依赖、不发送消息、不触碰生产数据。出现新的权限、需要改变既有契约或发现输入口径不一致时，要求 Codex 停下来报告，而不是自行选择更大的方案。

第三步：用独立证据验收

重新打开 README，检查限制文本仍在、建议只出现一次、sample.txt 未变化。记录 App 版本、账号状态、工作区路径、修改文件和未测试能力。退出再进入项目，确认任务仍指向同一目录，而不是最近打开的另一个仓库。

验收必须尽量脱离生成答案本身：安装类任务看版本、路径和真实启动结果；界面任务看目标视口与交互；数据任务用独立计算和异常清单；安全任务用原始复现、补丁 diff 与回归测试。把通过、失败和未验证分开记录，未验证不是失败，但绝不能伪装成通过。

完整案例

小林第一次使用 Codex，原本准备直接打开公司的主仓库。她先用练习目录完成验收：只读检查准确报出两个文件；批准后仅在 README 增加“如何验证”；系统文件时间戳证明 sample.txt 没变。第二次启动时 App 指向正确项目。她把这四条证据保存下来，之后进入真实仓库时，能分清登录故障、目录选择错误和任务本身的问题。

案例的重点不是复制同一句 prompt，而是观察决策顺序：先确定权威来源，再缩小动作面，最后让证据闭环。如果你的项目结构不同，保留这个顺序，替换文件名、命令和验收对象。任何会产生外部影响的步骤，都应在真正执行前再次获得明确授权。

故障诊所

若 App 无法登录，保留错误码、网络环境和发生时间，先核对官方状态与组织代理；不要循环重装。若 Codex 报出的目录不对，停止所有写入，重新选择项目并再次只读复述。若首次请求就产生了文件，保留 diff，撤销练习目录的改动，再检查指令是否真的写明只读和禁止创建。

恢复时一次只改变一个变量。先保存错误原文和当前状态，再判断问题属于安装路径、权限、上下文、实现还是验收环境。不要连续重装、重写和切换工具，因为那会抹掉因果关系。修复后重复最小复现，再跑相邻路径，确认没有用一个新问题遮住旧问题。

迁移练习

再创建一个含三个虚构文件的练习仓库，其中一个文件名带空格。让 Codex 只读生成目录说明，并故意从相邻目录启动一次，观察路径证据怎样暴露错误现场。最后写一张“进入真实项目之前”的五项检查卡。

完成练习后，把其中的产品名和文件名遮住，只保留“输入—动作—证据—停止条件”。如果这四项仍能指导另一个任务，说明你学到的是方法；如果离开示例 prompt 就不会继续，回到任务现场，补出你真正依赖的判断规则。

把安装结果变成以后排错的基线

保留 App 版本、账号状态、绝对路径、首次只读输出和文件状态。以后遇到问题时，你就能先排除安装与目录，而不是把所有异常都怪给 prompt。

进入真实仓库前再读一遍限制：建议不是授权，登录成功也不会扩大任务边界。

完成检查

• 安装来源与账号状态来自当前官方页面
• 首次工作区不含公司、客户或家庭敏感资料
• 只读请求前后文件数量与时间戳已核对
• 第一次写入只改了明确批准的文件
• 我保留了开始状态、实际动作和最终证据
• 我把失败、未验证和已通过分开记录
• 需要新权限或外部影响时，Codex 会停下来询问