一图速览
关键结论
- 从 PM 拆解、测试先行、实现、浏览器验证到 GitHub 推送，一套适合独立开发者的 AI 编程工作流。
- 这篇文章主要影响关注「AI 编程」的开发者、技术负责人和内容读者。
- 后续应继续观察它在「AI / 研究」里的真实采用成本、替代路径和长期影响。
影响对象
- AI 编程 相关开发者和技术负责人
- 正在跟踪 AI / 研究 趋势的产品与工程团队
风险 / 机会
| 机会 | 风险 |
|---|---|
| 把原有正文沉淀为可扫描的判断框架，降低读者理解成本 | 旧文没有完整 AI 初稿上下文，结构化判断需要后续人工复核 |
| 用封面、一图速览和表格提升转发与复读效率 | 如果后续事实更新，旧文中的判断需要同步修订 |
我的判断
这篇旧文值得保留，但不能只以段落形态存在。我的判断是：先把它补成「事实 + 解读 + 判断」的结构化版本，让读者能快速判断是否相关；后续若进入正式重写流程，再用最新信源替换这里的保守判断。
代码卡片
信源对比
| 信源 | 角色 | 关键事实 | 用途 |
|---|---|---|---|
| #1 | 站内旧文 | 既有正文与标题摘要 | 作为 backfill 的基础语料 |
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. 后续可以自动化，但不要第一天就自动化
第一版应该先人工精选，建立内容标准。等连续更新两到四周后，再把抓取、摘要、去重和排版自动化。
最值得自动化的不是“写文章”，而是：
- 收集信源
- 去重和初筛
- 生成结构化草稿
- 发现断链和重复选题
- 输出网站与公众号两种格式
把 AI 当作工程协作者，而不是魔法按钮，才是这套工作流能长期稳定的关键。