让 AI 编程走在正确轨道上的三件事
来源: X (Twitter) | 作者: ErwinWu000 | 2026-09-02
URL: https://x.com/ErwinWu000/status/2094991204375240733
- id: '2094991204375240733'
author: ErwinWu000
bio: |-
🎓PolyU PhDing | 💻ex Alibaba & Shopee
AI Builder丨AI x Design Researcher
Build in Public, study in public
text: >-
昨天资深程序员卡颂大佬 @kasong2048 引用我推文时提了一个很关键的点：AI 审代码挑出来的很多问题往往不是编码失误，而是需求没对齐导致 AI 只能脑补。
顺着这个思路，我在这篇帖子里系统梳理了一下怎么让 AI 编程真正走在正确的轨道上，建立一套系统让整个事情从“整点东西玩玩”变成“可靠的系统工程”。
整件事的核心其实就是三件事。目标对齐（定义你程序的终点）、路径探索（找到通往重点的路径）、循迹前行（确保走在正确的路上）
ps: 这篇帖子的知识密度非常大，深度总结了我在大厂实习和日常AI开发中的流程管理实践，希望能对大家有所启发。
1️⃣ 目标对齐
⚠ 这一步的核心目标是定义好你程序最后要到达的重点在哪里。
很多时候我们丢给 AI 的 Prompt，往往是一个带着个人偏见的半成品解法。
比如你跟 AI 说“帮我做个支持微信登录和购买会员的功能”，你以为需求已经交代清楚了，但你实际业务里藏着的“支付超时怎么回退库存”、“微信回调重复通知如何做幂等校验”、“多端登录时 Token 如何刷新”等一大堆隐性上下文，AI
根本看不到，只能基于训练集的概率分布在解空间里硬猜，结果做得跟你想的不一样又让人恼火。
图灵奖得主 Fred Brooks 早就说过：“构建软件系统最困难的单一环节，就是精确决定要构建什么。” 没有哪个环节做错会对系统造成如此致命的破坏，事后也最难纠正。
需求工程（Requirement Engineering）的核心本质就是两件事：
消除隐性假设：把那些你以为大家都默认，但其实谁都没写明的边界条件、灰色地带和异常流提前逼出来。
建立唯一事实来源：把脑子里模糊的想法，固化成一份精确的规格说明（Spec）。
🛠️ 落地实践：grill-me，grill-with-docs (来自matt pocock/skills)
它们的本质都是苏格拉底式需求获取（Socratic Elicitation）。核心思想是让AI
先别急着敲代码，先扮演严苛的架构师反过来“拷打”你：“并发边界是多少？”“第三方服务挂了怎么降级？”“数据冲突怎么处理？”直到把所有隐藏假设剥离干净，自动落成一份清晰的产品和技术规格文档。
2️⃣ 路径探索
⚠ 这一步的核心目标是找到通往程序终点的可能路径。
需求确定之后，通向目标的路径往往不止一条。而且每条路往下走，还会分出各种各样的技术分支。
很多时候某条路能不能走，不仅要看能不能实现，还得放在你当前工程的具体局限下去权衡。我通常会看这四个维度：
实现的复杂性：初始交付的技术门槛高不高？
维护的复杂性：未来会不会变成技术债？模块耦合度有多大？
时间与资源成本：第三方依赖贵不贵？开发周期赶不赶？
方案的可逆性：如果走不通，调头推倒重来的代价有多大？
但现实往往更复杂。方案选出来后，你也未必百分之百确定它可行，必须先去探索——也就是大家常说的先 probe（探一下），探通了才敢继续踩油门。
因为通往最终需求的路径本身就是一个拓扑网络，中间充满分支和不确定性，所以一开始必须有宏观的架构规划。先规划好整个体系大概长什么样，既能在宏观上统一各个细小的实现分支，也能在后续某个分支调整时，把对整个系统的冲击降到最低。
在动手前，借鉴 ADR（架构决策记录） 的思路：明确写下“背景-决策-后果与代价”，先定拓扑，再定具体实现。
🛠️ 落地实践：wayfinder + research + prototype (来自matt pocock/skills)
wayfinder：负责全局拓扑规划与路径导航，把不同的架构路线拆解、对比；
research：当某个分支可行性存疑时，自动触发技术探针（Spike），去检索最新文档、测试第三方 API 边界；
prototype：借鉴《程序员修炼之道》里的示踪弹（Tracer Bullets）思路，用极简代码端到端打通一条核心通路，用最小系统验证这个方案到底能不能闭环。
3️⃣ 循迹前行
⚠ 这一步的核心目标是保证自己走在正确的轨道上不偏离。
进入编码阶段，很多人用 AI 容易陷入“盲盒式开发”——一轮接一轮地把需求抛给 AI，闭着眼睛连续点 Accept，完全不记录中间改动了哪些模块与底层设计，直到某天系统突然崩溃，你和 AI 都不知道这堆逻辑到底是怎么长成现在这样的。
这种缺乏治理的开发很容易遇到两个失控点：
上下文漂移（Context Drift）：对话轮次一多，AI 就会逐渐忘掉早期的架构约束，甚至拿着过时的旧方案在上面乱改。
局部测试陷阱（False Green）：AI 写的单元测试全绿，但真正拼起来时，整个系统完全跑不通。
🛠️ 落地实践①：活文档与变更追溯 to-spec, to-ticket (来自matt pocock/skills) , docs-by-versions (来自https://t.co/w2V4odtaB9,本人自制)
开发中的每一个改动都必须有迹可循：
· 每次要做方案调整（增加新需求或改动已有需求），改动前要进行变更影响分析，先评估会波及哪些模块和接口，
· 对于新增的需求，如果不涉及对原有系统的更改，走to-spec, to-ticket的常规需求开发流程
· 对于要修改已有系统的改动，需要开一张变更单（CR），再to-ticket，执行
🛠️ 落地实践②：建立最小可用的 E2E 验收
在 AI 编码场景下，纯 TDD（测试驱动开发）有一个被广泛诟病的硬伤：AI 极其擅长为了让测试断言通过而硬凑代码，经常写出很多打补丁式的垃圾逻辑，彻底牺牲了代码结构的合理性。
所以必须结合 BDD（行为驱动开发） 的思路：
· 后端和数据库交互，交给自动化的 API 契约测试。
· 前端和交互界面，AI 往往不会主动去写健全的 UI 自动化。这时必须由人类开发者把自己代入真实用户，梳理出关键用户流程，写一个覆盖完整体验流程、最小可用的端到端集成验收测试（E2E Smoke Test），作为交付的物理硬指标。
4️⃣ 总结
这三步不是孤立的技巧，而是一套环环相扣的工程闭环：
· 定义目标（起点）：如果目标没扣死、隐性假设没剥离，后面走得再快也是在错误方向上狂奔；
· 找到路径（骨架）：如果只看眼前、不去探清路径网络与架构分支，执行时就会频繁撞墙、反复推倒重来；
· 保证实施（护栏）：如果缺乏变更追踪和端到端验收，就算目标和路线再完美，对话轮次一多也会在执行中悄然失控。
目标、路径、执行，三环紧扣。把这套工程约束建起来，AI 才能真正从单点修修补补的玩具，变成可以交付复杂工程的可靠生产力。
likes: 513
retweets: 101
created_at: Wed Sep 02 03:30:00 +0000 2026
url: https://x.com/ErwinWu000/status/2094991204375240733
has_media: true
media_urls:
- https://pbs.twimg.com/media/HRJ4Ol1agAAq8dV.jpg
- https://pbs.twimg.com/media/HRJ4Ol2aYAAG507.jpg
card: null
[... 原轴 thread 截取前 3500 字, 完整内容见 opencli twitter thread 输出 ...]
来源: X (Twitter) 线程，通过 opencli twitter thread 抓取。