两个月前，我更多把 AI Coding 当成效率工具：让模型读代码、写代码、修 Bug，最好再顺手跑一下构建。深度使用两个月后，我发现真正变化的不只是写代码的速度。
先放一张使用记录。
里面最显眼的可能是“最长任务时长”。先解释一下：这不是我和 Codex 一直在奋战。真实情况是任务执行到授权环节卡住了，我没注意到，安心过了个周末，回来才发现它还停在那里等我点头。
所以这项记录里，Codex 的主要贡献是耐心，我的主要贡献是忘记检查。
比这些使用数字更有价值的是，这两个月里，我逐渐把 Codex 从“会写代码的聊天框”，用成了一种能够进入真实工程、处理长任务，并参与验证和交付的工作方式。
从让 AI 写代码，到让它完成一段工作
刚开始用 Codex 时，我也会把任务写成一句话：实现某个功能、修复某个错误、优化某个页面。
短任务通常没问题。真正进入已有项目后，问题很快暴露出来：它可能在错误的子仓库里工作，可能把旧接口当成当前接口，也可能构建通过就宣布完成，却没有验证浏览器里的真实状态。任务越长，越容易出现“代码看起来合理，但结论并不可靠”的情况。
后来我的要求变了。
现在开始一个任务，我会先让 Codex 找到真实 Git 根目录，读取当前仓库的 AGENTS.md，确认分支和未提交修改，再去定位接口、数据结构和现有组件。实现之后还要沿原路径验证：后端改动看接口和测试，前端改动看真实浏览器状态，桌面端看真实进程和窗口，交付前再检查 diff、暂存区和分支状态。
这看起来比一句“帮我把功能写完”麻烦，但它反而让长任务更快。因为真正浪费时间的从来不是多读几个文件，而是在错误前提上写出一大批看似正确的代码。
从这里开始，写代码只是任务的一环。我更关心 Codex 能不能理解上下文、拆解任务、调用工具、验证结果、记录缺口，并在明确的授权范围内完成工作。
两个月里，我做成了什么
这段时间，Codex 参与过 Rust、Java、React、Vue、Tauri 等不同技术栈，也做过接口对齐、权限排查、UI 迁移、浏览器验证和构建交付。如果只选两个最能代表这两个月沉淀的项目，我会选 skills 和 rustzen-admin。
1. 把经验沉淀成 16 个可复用的 Skills
我维护了一个公开的 Agent Skills 仓库。目前包含 16 个独立 Skill，覆盖仓库分析、领域建模、产品规格、前后端开发、Rust/Java/前端审计、代码 Review、Git 交付、浏览器与客户端验证，以及技术写作。
最初我也把 Skill 理解成“更长、更专业的 Prompt”。真正使用一段时间后，我发现两者差别很大。
一个能长期复用的 Skill，至少要说清楚几件事：什么时候触发、证据从哪里来、哪些事情归它负责、哪些事情不能做、完成后输出什么、怎样验证它没有越界。
例如，repo-review 只负责基于明确范围做只读审查，不自动修改代码；repo-delivery 负责提交、同步和分支交付，但不会把“允许修改”误解成“允许推送”；ops-browser 负责浏览器里的真实证据，不会把构建成功当成页面已经正确。
我还做了一个比较特殊的 ask-chatgpt。它让我可以从 Codex 当前任务里向真实 ChatGPT 发起提问或独立审查：Codex 先整理问题、证据和限制，只有在我明确授权后才会发送；拿回的意见也不会直接照单全收，而是回到本地代码或文档逐项核对。这篇文章在定稿前，就用这条路径做过一次独立审查。
这些 Skill 不是我坐下来一次设计出来的。它们大多来自真实失败：错误地进入父目录、把静态扫描当成运行时证明、忽略脏工作区、在没有授权时扩大 Git 操作、把设计截图和浏览器计算结果混为一谈。
每出现一类重复问题，我就把边界、证据和验证方法沉淀下来。久而久之，Codex 不再每次从零理解“我希望它怎么工作”，而是可以复用一套稳定的工程习惯。
如果你也在高频使用 Codex，我建议不要一开始就收集几十个 Skill。先找出自己最常重复说明、最容易返工的那一类任务，把它做成一个真正可验证的 Skill，比安装一大堆看起来很强的模板更有用。
2. 持续演进一个真实的 Rust 全栈项目
另一个代表性成果是我维护的 rustzen-admin。这是一个面向小型自托管环境的 Rust 全栈管理与运维项目，包含 Axum 后端、React 前端、SQLite、部署资产和多个独立运行时，最近还增加了只读的统一运维命令 rz。
我选择它，不是因为技术名词多，而是因为这类真实项目很难靠“生成一段代码”完成。它同时涉及架构边界、权限、前后端协作、安装发布和文档一致性，任何一层只做到“差不多”，都会在集成时暴露出来。
过去两个月里，我用 Codex 参与了模块边界收敛、共享契约整理、权限加固、前端组件体系迁移、登录页响应式验证、发布结构调整和 rz CLI 的实现。这里最重要的收获不是“AI 能写 Rust”，而是它能够在明确约束下跨越多个层次工作，并保持同一个产品目标。
当然，前提是人不能退出决策。哪些模块应该合并、哪些故障域必须独立、CLI 能不能执行写操作、什么证据才算完成，这些都需要我先做出判断。Codex 可以把决定落到几十个文件里，但不能替我承担产品和工程责任。
几次返工后留下的五条规则
一、上下文质量比提示词技巧重要
我现在很少追求一句“完美 Prompt”。相比修辞，更重要的是让 Codex 读到正确的仓库规则、接口定义、现有实现、错误日志和验证命令。
接口参数以 Controller 和 DTO 为准，UI 结构以当前组件和设计证据为准，Git 状态以当前工作区为准。上下文一旦选错，模型越努力，返工可能越大。
二、把“完成”改写成可验证的证据
“已经修好”“应该没问题”“构建通过”都不是一个完整结论。
我会明确要求它说明：改了什么、验证了什么、验证覆盖到哪里、还有什么没有验证。前端构建通过，只能证明构建；真实页面是否正确，还要看浏览器。设备控制接口返回 true，也不能证明物理设备真的转动了。
这种区分会让结果显得没那么漂亮，但可信得多。
三、授权边界要写清楚
修改代码、提交、合并、推送和发布，是五件不同的事。
长任务里最危险的不是模型不会做，而是它把“继续完成”理解得太宽。我的做法是提前约定边界：默认保护无关修改，不做破坏性清理，不因为完成了代码就自动推送，更不会把测试环境的成功外推成生产验证。
四、Skill 应该来自重复发生的问题
Skill 的价值不是让指令看起来更专业，而是减少同一类错误再次发生。
如果一个任务只做一次，写清当前要求就够了。如果一个边界需要反复解释，或者相同错误已经出现两三次，就值得把它沉淀成 Skill，并给它补上失败案例和验证方法。
五、深度使用之后，瓶颈会回到人身上
Codex 可以同时阅读大量文件、执行命令和持续工作很久，但人的注意力没有同步扩容。任务越多，越需要决定优先级、检查结论、拒绝不必要的重构，并及时停止已经没有收益的迭代。
我现在花在逐行敲代码上的时间少了，花在定义问题、判断边界和验收证据上的时间多了。这不是工程师退出了开发，而是工作重心从“亲手完成每一步”转向“确保整条路径是对的”。
接下来：让 Codex 跑通产品到测试的完整流程
接下来我想继续验证一件事：能不能让 Codex 串起产品定义、UI 设计、研发实现和测试验收，真正跑通一条完整的软件交付流程。
这不是让 AI 独立决定一切，而是把每个阶段的输入、输出和验收标准定义清楚：产品阶段形成可实现的需求与规则，UI 阶段保留设计依据和交互状态，研发阶段按仓库契约落地，测试阶段沿真实运行路径验证结果。Codex 负责衔接上下文和推进执行，人负责方向、取舍与最终验收。
我希望最终留下的不是一次看起来成功的 Demo，而是一套可以重复使用、能够在不同项目中稳定运行，并且每个环节都有证据可查的协作流程。
相关项目：