停止信息碎片化
Source: Dev.to
AI 不是搜索引擎
大多数人使用 AI 的方式就像使用搜索引擎一样：
- 有一个问题
- 提出问题
- 获得答案
- 继续下一个问题
每次交互都是独立的；上下文会被重置。人类掌握完整的全局，而 AI 只能看到碎片。
为什么碎片化方法会失败
当你将信息碎片化时，AI 无法：
- 看出问题与更大目标之间的关联
- 识别与先前决策的矛盾
- 提出你未曾考虑的替代方案
- 捕捉系统内部的不一致
于是你成为瓶颈——需要手动将 AI 的零散答案综合成连贯的工作。实际上，你把协作者当成了查找表。
连续信息流
Instead of fragmenting, maintain a continuous information flow:
Requirements → Constraints → Specifications → Design → Implementation → TestAI 参与整个链路，因此在交互之间不会丢失任何信息。
Stakeholder wants:
- User authentication
- Dashboard for metrics
- Export to CSV
- Real‑time updates
- Mobile support
- Integration with existing CRM
- Audit logging
在此阶段，AI 帮助你全面捕获信息，而不是进行评估。
2. 按业务价值和依赖关系进行优先级排序
| Priority | Feature(s) |
|---|---|
| Must have | Authentication, Dashboard, CRM integration |
| Should have | Export, Audit logging |
| Could have | Real‑time updates, Mobile support |
AI 可以挑战你的优先级，例如：
“如果 CRM 集成是必须具备的，那么审计日志是否也应该是必须具备的以满足合规要求？”
3. 在寻求解决方案前定义边界
- 预算： 3 名开发人员，2 个月
- 技术栈： .NET，PostgreSQL（现有基础设施）
- 安全性： 必须符合 SOC 2 合规性
- 性能： 1 000 并发用户
现在 AI 能够了解在你的上下文中“好”意味着什么。
4. 识别缺失或模糊的项目
Prompt: “Given the requests and constraints above, what’s missing or ambiguous before we can write specifications?”
可能的 AI 回答
- “实时更新 + 1 000 并发用户 需要明确延迟要求。”
- “CRM 集成：是哪种 CRM？数据流向是什么？”
- “移动支持：是原生应用还是响应式网页？”
回到利益相关者那里，填补这些空白，并更新共享的上下文。
5. 编写规格说明书
在拥有完整、干净的上下文后，AI 帮助生成的规格说明书将会：
- 与约束条件保持一致
- 完整（已解决所有缺口）
- 可追溯到最初的请求
从需求到交付
| 阶段 | 在清晰上下文下 |
|---|---|
| 设计 | AI 提出符合约束的架构 |
| 实现 | AI 编写符合规格的代码 |
| 测试 | AI 生成验证需求的测试 |
| 审查 | AI 检查是否符合既定标准 |
需求阶段不是负担；它是使其他所有工作高效的投资。当 AI 理解你的需求时，它甚至可以 挑战你的约束。
碎片化 vs. 连贯化 方法
| 碎片化 | 连贯化 |
|---|---|
| “我该如何在 C# 中解析 JSON？” | “考虑到我们的数据管道需求，最佳的解析策略是什么？” |
| “为此方法编写单元测试。” | “根据我们的规格，这个测试应验证什么？” |
| “审查这段代码。” | “该实现是否满足我们设定的约束条件？” |
碎片化的方法会给你答案；连贯化的方法会给你 对齐的答案。
保持跨会话的思考过程
当 AI 只收到经过润色的结论时，它会错过：
- 你考虑过并且拒绝的选项
- 你辩论过的权衡取舍
- 你尚未解决的不确定性
- 你搁置的“以后再说”想法
这些思考的波动会转化为后续的权衡取舍。
解决方案： 使用共享记忆系统（日志、差异记录、进度笔记），让 AI 可以引用。这样，一个月后你可以说，“还记得我们讨论过 OAuth 的权衡吗？”，AI 就能准确理解你的意思。
什么是完整上下文
| Element | Purpose |
|---|---|
| Requirements | 我们要解决什么问题？ |
| Constraints | 有哪些限制？ |
| Decisions made | 我们已经做出了哪些决定？ |
| Decisions deferred | 还有哪些未决定？ |
| Dependencies | 与哪些内容有关联？ |
| History | 我们尝试过并且放弃了什么？ |
这是新成员需要的全部信息，以便有意义地贡献——也是 AI 成为真正协作者所需的信息。
超越提示工程
结构和文化方法如何在 AI‑辅助开发中胜过提示优化
问题：信息不对称
当你拥有 AI 没有的信息时：
- AI 会做出合理的假设（恰好是错误的）
- 你反复纠正 AI（浪费循环）
- AI 的建议不合适（因为它看不到约束）
- 你得出 AI 没用的结论（因为你限制了它）
消除不对称后会发生什么
- AI 的首次响应更接近可用
- 修正变成细化，而不是重新指向
- 建议考虑真实约束
- 合作变得高效
信息不对称是碎片化的隐藏成本。
转变描述简单，实践困难。
两种对比的协作模式
| Google 模式 | 合作伙伴模式 |
|---|---|
| 卡住时提问 | 持续共享 |
| 提供 最小 上下文 | 提供 完整 上下文 |
| 接受 答案 | 讨论 含义 |
| 人类 综合 | AI 参与 综合 |
合作伙伴模式将 AI 视为真正的合作者，接收完整的全局信息，而不是仅在你没有想法时才调用的工具。
如何采用合作伙伴模式
- 信任 AI，提供完整的全局信息——给它所有相关数据、约束和目标。
- 把 AI 当作合作者——期待它参与综合，而不仅仅返回孤立的答案。
- 持续共享——在新信息出现时更新模型，而不是等到陷入死局。
- 讨论含义——把 AI 的输出作为更深入对话的跳板，而不是最终结论。
行动号召
停止碎片化。开始共享。
通过从“Google‑式”查询模型转向真正的合作伙伴关系，你将 AI 从被动的搜索引擎转变为主动的共同创作者。这是 “超越提示工程” 系列的核心信息。