AI 编程工具最容易被误用成“更聪明的自动补全”。真正高杠杆的方式，是让它进入软件交付的每个环节：理解目标、拆任务、写测试、实现、验证、复盘。

1. 先让 AI 做 PM，而不是直接写代码

一个含糊的需求通常会变成含糊的代码。我的默认做法是先让一个模型担任 PM，输出用户画像、MVP 边界、信息架构、验收标准和任务优先级。

这样做的价值不是“多一个文档”，而是让后续开发有明确的停靠点：每个任务都知道自己为什么存在，以及怎样算完成。

2. Codex 更适合做工程执行闭环

Codex 在本地代码库里能读文件、改文件、跑测试、看浏览器结果。它适合承担这些工作：

  • 把 PM 的方案落成项目结构
  • 先写可测的核心逻辑
  • 实现页面和交互
  • 启动本地服务做视觉与功能验证
  • 整理 Git diff，推到 GitHub

3. 每个任务都要有验收标准

我会把任务写成类似这样：

任务：实现每日更新页
验收：/daily/2026-05-23 可访问；条目按四支柱分组；昨天/明天只在有数据时出现；移动端无横向滚动。

有验收标准，AI 才不会在“看起来差不多”的地方停下。

4. 内容产品也需要测试

技术日报不是传统软件，但仍然需要测试：

  • Markdown frontmatter 必须符合 schema
  • 新增日期后首页要自动取最新一期
  • 分类页要按支柱过滤
  • RSS 要能订阅
  • 页面要在移动端可读

这些测试能避免“今天内容发出来了，但链接打不开”的尴尬。

5. 后续可以自动化，但不要第一天就自动化

第一版应该先人工精选，建立内容标准。等连续更新两到四周后，再把抓取、摘要、去重和排版自动化。

最值得自动化的不是“写文章”，而是：

  1. 收集信源
  2. 去重和初筛
  3. 生成结构化草稿
  4. 发现断链和重复选题
  5. 输出网站与公众号两种格式

把 AI 当作工程协作者，而不是魔法按钮，才是这套工作流能长期稳定的关键。