AI工具在软件开发中的应用指南

AI工具在软件开发中的应用指南

见过不止一次AI滥用的滑稽故事。

AI 工具编写的用户故事的问题

大多数在迭代优化中使用 AI 的团队都走错了方向。他们让AI 从零开始编写用户故事，然后把剩下的时间都花在修正 AI 的错误上。其实有更好的方法，而且不需要把我们的待办事项列表交给ChatGPT。AI 生成的用户故事存在一个特定的缺陷：它们听起来很完美。语法正确，格式规范，结构合理。“"As a user, I want to filter results so I can find what I need." 从技术上讲，这确实是一个用户故事。但它实际上可以用来描述任何曾经开发过的产品。

这些故事在优化阶段往往被快速浏览，因为没有人会质疑它们读起来很流畅的内容。然而，在迭代开始两天后，负责实现这些故事的开发人员却面临着五个需要澄清的问题，却找不到任何答案。亲眼目睹过这种情况。团队在优化阶段节省了10 分钟，却在接下来的一周里浪费了两个小时在反复沟通上。

人工智能的真正价值所在，真正节省时间的是在人类完成初稿后使用人工智能。具体来说：扩展验收标准。我们先编写出理想情况，然后将其输入到LLM中，并询问：“我遗漏了哪些边界情况？我做了哪些假设？”它会发现我们未考虑到的空状态、权限边界、并发问题和错误路径。凯捷咨询公司2024年的一项调查发现，人工智能扩展的验收标准减少了约15%的返工单。节省的细化时间固然可喜，但减少迭代中期的意外情况才是真正的优势。

他们先用 AI 工具编写用户故事，接着又用AI 对其进行总结。产品负责人（PO）让工具来撰写用户故事，结果故事变得更长，细节更多，涵盖的边缘情况也更丰富，开发人员因此需要阅读更多的文字，于是，其中一些人又用AI 工具把故事缩减了回去，这既滑稽，又反映出关注点完全错了。

👉用户故事不是一份文档，它是一份关于“进行沟通”的承诺。把文档写得冗长并不能帮助团队，它反而掩盖了一个事实：沟通从未真正发生过。“承诺沟通”的说法完全正确，而且值得更进一步：在AI出现之前，沟通就已经缺失了。有人在写冗长的故事，而另一个人只是默默地阅读，没有交流，而这个工具只是加快了循环的两端。人工智能工具制造了这种逃避，估算也是如此。让人工智能工具评估待办事项，它会在十秒钟内给出清晰的要点和可靠的数字，而这个故事甚至还没有人真正解释清楚。故事并没有变得更清晰。它只是得到了一个穿着白大褂、更花哨的猜测而已，现在这个工具可以在当天下午就跳过沟通和计算。

👉组织管理层报告上也见过类似的情况，过去，人们花大量时间制作幻灯片。如今，AI让幻灯片制作得既快又美观，管理层收到的报告页数变多了，工作看起来似乎比实际情况更确定、更稳妥，关键信息反而更难找了，而且，依然没有做出任何决策。

💡 人工智能工具生成的文档也是如此：更多的文字，更少的信息，浪费时间。生成式人工智能工具降低了人们的生产力，尤其是在不该自动化的事情被自动化的时候。人工智能擅长的很多事情，恰恰是去做那些原本就不应该做的事情。与其使用人工智能来搞砸它，为什么不考虑干脆不做呢？

💡如果一份报告无法推动决策，那就别写了，不要试图加速一个毫无用处的步骤。先问问这个步骤是否有存在的必要，然后简化它，最后才考虑使用AI。如果一开始就搞自动化，可能会去打磨一个愚蠢的流程，对其进行优化，甚至实现自动化，最后才发现——其实根本就不需要这个流程。

停止人工智能工具编写用户故事！使用规范驱动开发，规范驱动开发是人工智能编码工具和生产就绪软件之间缺失的一层。人工智能工具没有直觉。它依靠的是模式匹配——当模式不完整时，它就只能猜测。这种猜测有一个名字：幻觉。当我们把一个模糊的用户故事交给人工智能编程助手时，我们不是在给它设定要求，而是在给它一个进行创造性想象的起点。它会自行创建数据库模式、捏造API 端点，并假定一些从未讨论过的安全边界。输出结果看似合理，但往往并不正确。解决办法不是改进提示，而是改进规范。

系统优先的规范框架

ZeeSpec 是一种结构化的软件规范方法，它优先考虑维度完整性而非叙述便捷性。它不是描述用户想要做什么，而是描述系统是什么——从借鉴自 Zachman 框架的六个维度进行描述：

每个维度都是独立定义的。然后——这也是ZeeSpec 的强大之处——维度之间的交集就变成了显式的约束条件。

系统的引力：维度交汇

在 ZeeSpec 中，网格的对角线和横截面单元格不仅仅是文档。它们代表了我们所说的系统的“引力” ——将系统维系在一起并定义其内部可能性的力。

内容 × 内容：核心标识（域完整性）

“是什么”维度与其自身的交集定义了领域模型的内部一致性。它不是实体列表，而是对实体之间唯一有效关系的声明。举例对于图书馆系统而言：aBook和 bMember存在。What×What 的交集告诉人工智能，aLoan是连接它们的唯一有效桥梁。一个会员可以有多本借阅书籍。一本书在同一时间只能有一个有效的借阅记录。这对人工智能的重要性在于：这相当于一个防幻觉机制。如果一个实体没有在“What×What”定义中声明，人工智能就被明确禁止为其创建表或对象。这样就不会出现幽灵实体、虚构的连接表或意料之外的多态关系。

内容 × 位置：数据拓扑（隐私和架构边界）

“内容”（数据）和“地点”（网络/基础设施）的交集定义了特定数据存储在哪里以及谁可以访问它。

对于同一图书馆系统：

Book目录数据 → 缓存于Redis，可通过 CDN 公开访问

Member个人身份信息 (PII) → 静态加密，存储在私有子网中，符合加拿大《个人信息保护和电子文件法》(PIPEDA) 的数据库

Loan记录 → PostgreSQL RDS，仅可通过经过身份验证的内部 API 访问

这对人工智能的重要性在于：当人工智能看到一个Loan映射到数据库的实体时PostgreSQL RDS，它知道应该编写一个带有连接字符串的数据库驱动程序，而不是本地JSON 文件。更重要的是，它知道Member家庭住址绝不能出现在公共API 响应中，因为“是什么×在哪里”的交集明确禁止这种暴露。这使得模糊的隐私要求转化为机器可读的架构约束。

杀手级功能：间隙检测

这就是 ZeeSpec 与“编写更好的文档”的区别所在。当我们描述“内容”（信用卡信息）而没有定义“存储位置”（符合PCI标准的存储）时，支持ZeeSpec的AI代理不会进行猜测，而是会标记出这个差距。

这会将规范从被动文档转变为架构的主动代码检查层。网格中的每个非对角线交叉点都代表一类风险，系统必须在编写任何一行代码之前解决这些风险。完整的风险矩阵如下所示：

ZeeSpec与用户故事：直接比较

ZeeSpec人工智能辅助开发流程

ZeeSpec 并不会完全取代您现有的工作流程，而是在您编写任何代码或提示之前插入一个规范层：

填写维度网格——定义系统的六个维度中的每一个。

解决交叉问题——明确声明跨维度约束

运行间隙检测——识别任何未定义或相互矛盾的交叉点

生成.spec文件——每个维度一个文件（what.md，，，等等）where.mdwhen.md

将完整的规范（包括所有上下文，而不仅仅是用户故事）提供给人工智能。

生成代码——人工智能的功能仅限于规范允许的范围

人工智能的工作不再是解读意图，而是执行合同。

有效的工作流程和团队行之有效的模式

AI编码助手已经跨越了一个门槛。它们可以在几分钟内编写出涵盖整个功能的高质量生产级代码。瓶颈不再是生成速度，而是规范质量。那些能够借助人工智能辅助开发取得成功的团队，并非那些拥有最佳提示的团队，而是那些在开始生成提示之前，就投入资源使其系统约束条件能够被机器读取的团队。用户故事是人本开发流程的理想工具。但对于以人工智能为中心的开发流程，我们需要更精确的工具。

捕获依赖关系。如果我们将数据模型或 API 接口与用户故事一起提供给模型，它就能非常有效地标记出那些容易被人工审核忽略的跨团队依赖关系和迁移风险。关键在于上下文。仅提供用户故事文本的提示会给出通用输出。而提供用户故事加上我们的模式的提示则会给出我们可以采取的具体标记。

拆分大型用户故事。当一个用户故事明显超出迭代周期时，提示 LLM“按用户工作流程步骤拆分”或“按数据变体拆分”比要求其进行通用拆分效果更好。我们提供的模式比我们使用的模型本身更重要。

产品负责人编写包含基本验收标准的用户故事草稿（无需润色）。将每个用户故事连同相关上下文（数据模型、相关用户故事、约束条件）一起提供给LLM，并要求其列出边界情况、隐含假设和缺失的场景。

在细化阶段，团队共同审核 AI 的输出结果。剔除噪音，保留真正有价值的信息，基于更全面的信息进行估算。经过此流程的用户故事往往能更早地展现复杂性，从而减少在计划扑克过程中“等等，那……”之类的打断。

一些团队报告称，细化会议的时间缩短了 20-30%。但更大的收益会在迭代后期显现，届时澄清请求会大幅减少。

注意事项

虚假的完整性。人工智能生成了 12 条验收标准，团队误以为这已经涵盖了所有情况。事实并非如此。模型无法了解它对系统未知的部分。

技能退化。如果我们的初级开发人员因为人工智能代劳而停止学习如何分解工作，那么我们实际上是用短期的速度换取了长期的问题。让经验较少的人员编写初稿，然后使用人工智能进行扩展。

通用提示，通用输出。“编写一个搜索用户故事”这样的提示无法提供任何有用的信息。 “为管理50 多个项目的用户编写一个能够跨项目名称和描述进行全文搜索的用户故事”这样的示例，能让我们获得实际可用的素材。

何时完全跳过 AI 优化？对于具有清晰重现步骤的bug 修复、复制更改以及简单的 CRUD 操作，使用传统方法优化速度更快。将AI 优化留给那些问题空间模糊不清，或者团队在迭代过程中不断发现未知问题的用户故事。

8本149.99元

欢迎组织或团队内训

感谢关注，对读者有益、有帮助、有启发、有触动，哪怕一丝丝，我们很欣慰，来自读者和市场的接受、认可、肯定、赞赏，是我们持续改进、持续输出有价值内容的原力。