第2篇|我没有让Codex一次写完整个软件,而是把任务拆小了

做 aide-stock 时，我想要的是一套自己每天能用的 A 股研究工具。可如果只对 Codex 说“帮我做个选股软件”，它先做出一个漂亮页面，我也不知道里面的数据是否可靠。

我没有看过或手动修改这个项目的代码。我的工作是决定先解决什么问题、哪些事不能交给 AI 决定，再根据功能表现和 Codex 提供的检查结果判断能否继续。回头看项目记录，第一步确实很小：先让工程跑起来，再检查数据，之后才轮到筛选和分析。

我给 Codex 的不是一张“完整软件”清单，而是一段段有先后关系的工作。每段结束，都要有能让我判断的结果。

我先关心数据，再看它怎么选

6月14日留下的最早版本 v0.1，只有前后端框架、页面入口和基础设置。它让我看到项目能启动，还不能回答“今天有哪些股票值得研究”。

接下来我提出数据更新、缺失检查和任务记录。这个先后顺序对我很重要：交易日和行情数据如果有问题，后面排出来的候选名单再整齐，我也不敢拿它复盘。

数据层有了以后，项目才逐步加入因子、板块分析，以及候选池、风险池和观察池。候选池放值得继续研究的对象，风险池提醒问题，观察池记录后续表现。再往后，安全约束、公告事件、Agent 分析和回测反馈陆续接进来。

到了 v0.9，这些原本分散的功能才被收成日常工作流：今天先看什么，哪一步被数据或风险阻断，接着去哪里复盘。

图注｜aide-stock 的版本记录显示了从工程骨架、数据检查到研究池、AI分析和日常工作流的顺序。图中是能力之间的依赖关系，不代表各阶段耗时。

如果一开始就让 Codex 把最终页面全做出来，我很容易被“已经能点开”带着往前走。按这个顺序推进，我至少能先问清楚：页面里的结果从哪来，缺了数据会怎样，候选和买入决定有没有混在一起。

到了 v0.5，我发现一个版本也得继续拆

v0.5 要处理的事情一下多了起来：手动持仓、外部账本同步、盘前预案、交易计划，还有风险阻断。它们互相关联，出问题时却不能混成一句“交易模块还没做好”。

项目文档把这一版分成五个内部阶段。先建立交易约束、持仓和风险备注的底座；再接外部账本；接着做风险守卫与保守盘前预案；然后才生成带条件的交易计划；最后专门留一阶段做总体验收和发布记录。

我需要知道每一步交来的是什么。账本同步之后，差异有没有经过确认？风险守卫加上以后，原本应该阻断的动作会不会被放行？计划出现以后，它有没有写清触发和失效条件？这些问题比“页面又多了几个按钮”更能帮我判断项目是否在往正确方向走。

v0.5 文档要求按顺序推进：每个阶段完成后，Codex 停下来交付验收结果；人工未确认通过，就不进入下一阶段。这里的人工判断是产品与使用层面的验收，代码实现和测试仍由 Codex 负责。这个分工贯穿了我做 aide-stock 的过程。

现在让我再交一个任务，我会先说清五件事

回看版本文档和项目规则，我把这种做法整理成五个问题。这是事后的归纳，不是我当时每次发给 Codex 的原话。

目标：这一轮到底要看到什么结果？“把回测做好”太大；“先留下可追溯的反馈任务记录”就能单独检查。

现状：上一阶段已经交付了什么，Codex 应该先读哪些项目文档、代码和测试？这些文件由它去查，我负责说明现在遇到的使用问题。

范围：这次要交付哪些行为？例如反馈任务能创建、能看到状态、结果写到约定的位置。做到哪里停，最好在开始前说清。

边界：哪些事情暂时不能碰？aide-stock 的回测反馈不能自动改写当天使用的生产规则；整个工具也不接券商，不自动交易。

验收：Codex 要提供哪些测试和运行结果，我要在页面上看到什么，失败或数据缺失时怎样表现？“已经完成”三个字本身不够。

这五项里，验收最容易被一句“做完再看”带过。可如果事先没说清怎么验收，等 Codex 交付以后，我只能凭一个能打开的页面猜它做得对不对。

给读者的一张任务卡

如果你也在做自己的小工具，可以先把第一个任务写成下面这样，再把示例内容换成你的项目事实：

任务也不能拆到只剩“改一个按钮颜色”或“加一个变量”。我会让一次任务至少留下一个能观察的行为，比如数据质量页能指出缺失记录，或者风险条件触发后，计划明确退回观察状态。这样我才能根据交付结果给下一轮方向。

从 Git 记录看，aide-stock 也是这样一步步长起来的：数据接口、质量页、任务记录、因子计算，以及对停牌口径和页面结构的持续修正。1093 次提交是保存下来的改动次数，不能换算成 1093 个功能，更不能当成我逐行检查过代码的证据。

我做游戏开发，有判断软件是否顺手的经验；但在这个项目里，我没有进入代码层验收。要让 Codex 承担实现，就得让它把测试、构建和剩余风险一并交出来，我再看功能是否解决了原来的问题。这套方法来自 aide-stock 的版本与 Git 记录，公开的原始 Codex 对话不完整，我也不会补写一段看似精彩的历史提示词。

如果你今天准备开始自己的项目，我建议先做一件小事：写下第一条从输入到结果的流程，并给它一个明确的停止点。等这一步能被检查，再决定下一步。至于新想法该不该进入当前版本，还需要另一道范围判断。

参考来源

01｜OpenAI Codex 官方页面；查询日期：2026-09-18

https://openai.com/codex/

项目记录说明

本文中的版本顺序、任务边界、验收规则和提交示例，来自作者本地 aide-stock 仓库的 README、开发计划、v0.1—v0.9 版本文档、项目执行规范及 Git 提交记录，核查时间为 2026 年 9 月 18 日。提交数量只表示保存下来的项目改动，不等同于人工工时或独立功能数量。