防止返工的应用规范：约束与非目标

当规范缺少约束时为何会出现返工

返工是指你构建出能运行的东西，但对项目来说却是错误的产物。团队不得不重做界面、重写逻辑、迁移数据或重建某个功能，因为某个关键决策太晚才出现。

这类情况通常以熟悉的方式出现：某个流程被重做，因为假设了错误的用户角色；界面被重新设计，因为需要移动端支持但从未声明；数据模型被改动，因为“我们需要审计历史”是在第一版之后才提到；某个集成被替换，因为客户不能使用第三方服务；或者应用因为合规或区域规则不得不迁移托管。

缺失的约束会在后期带来意外决策。当规范只写“构建一个 CRM”时，留下了数十个未回答的问题：谁会使用、哪些平台重要、安全规则是什么、哪些必须排除在外、真实的预算和时间线是多少。如果这些答案在代码存在后才到来，项目就要付出双倍代价：先构建一次，再去撤销并重做。

举个简单例子：创始人要求“预约 + 提醒”。第一周上线了邮件提醒。第二周他们提到需要短信，但短信在他们国家不可用或会超出预算。现在提醒系统需要重设计，界面变更，测试重新开始。返工的原因不是糟糕的编码，而是晚出现的约束。

目标是在任何代码被编写或生成前，尽量减少来回调整。无论你是手工编码还是使用基于聊天的构建器，输出只能遵循你给出的规则。如果规则迟到，工作就会转移，你需要重做。

这并不是要你写一份冗长的文档。轻量级的规范也可以在关键点上很严格。早期应该回答：

• 什么是固定的（截止日期、预算、团队、评审节奏）？
• 技术上哪些是固定的（栈、托管、数据存放地）？
• 应用必须不做的事（非目标）？
• 什么可以变更而不需要重开整个计划？

当约束和非目标先被写下来时，它们就像护栏。你会有更少的意外、更少的重建，从第一天起决策也更清晰。

约束 vs 非目标：一分钟内的区别

约束是项目必须遵守的固定决定。忽视它们你会做两次工作，因为你朝着无法发布的方向去构建。

非目标是明确地选择不去构建某件事。跳过它们，规范会在无人注意中膨胀，人们会加入“几个小功能”。这就是为什么你最终要重做界面、流程和数据模型。

一个简易规则：约束限制你如何构建；非目标限制你构建什么。

什么算是约束

约束是不会在没有真实决策（以及相应权衡）下改变的必须项。

示例：

• “我们必须在 6 周内上线。”
• “预算上限为 $15k。”
• “必须仅在欧盟运行以满足数据驻留要求。”
• “前端必须是 React，后端必须是 Go，数据库必须是 PostgreSQL。”

当一个约束是真实的，把它写成一个无法争辩的句子。如果有人能说“也许”，那它还不是约束。

什么算是非目标

非目标是明确的“我们不做这件事”，即便它看起来有用。它保护了初始版本的范围。

示例：

• “v1 不做移动应用，仅限 Web。”
• “上线时不支持多语言。”
• “不做实时聊天；邮件通知足够。”

非目标并非消极，它们防止昂贵的旁路工作。例如，“v1 不做自定义角色”能节省处理权限边缘情况的数周工作，这些问题会迫使数据库和界面重设计。

从一句话和小范围的成功定义开始

在写大量细节前，先写一句话把项目钉住。它在权衡出现时保持每个人一致。

一句好的一句话回答：这是为谁做、要完成什么主要工作？

示例一句话：

• “为独立导师提供的简单 Web 应用，让学生能预约课程并接收提醒。”
• “为小型诊所提供的移动应用，让工作人员查看今日预约并记录基本就诊笔记。”

然后添加一个小的成功定义：3 到 5 个真实用户在项目完成时应能达成的结果。用用户结果来写，而不是功能。

对导师预约示例：

• 导师能够在几分钟内设置一周的可用时段。
• 学生能在线预约而无需打电话或发邮件。
• 双方都会收到确认和提醒。
• 导师可以在手机和笔记本上清晰查看每日日程。

如果你还没有指标，用文字描述成功。“快”很模糊，但“在手机上感觉响应迅速”仍有用。“容易”较模糊，但“无需设置电话”更清楚。以后可以再加数字。

把这一部分保持简短。它成为后续所有内容的上下文：必须成立的事、不能发生的事、以及可以变更的事。

写出固定的项目约束（时间、预算、人员）

返工往往始于日程和决策流程只存在于某人的脑中。在描述界面和功能前，把项目约束写进规范。

把它们写成简单、可测试的陈述：

• 截止与里程碑： 上线日期和 2 到 3 个检查点（规范签字、原型批准、首个版本就绪），并说明首发包含哪些内容。
• 预算： 是硬上限还是目标范围。说明包含哪些内容（构建时间、设计、测试、托管、支持），以免日后重新争论。
• 人员与可用时间： 谁来评审以及他们回应的速度。缓慢的反馈本身就是约束。
• 决策所有者： 在出现权衡时有权说是或否的人。

一个简单示例：

“首发必须在 5 月 30 日前上线。包含登录、基础客户列表和一份月报。v1 不做任何集成。预算上限为 $8,000（包含首月托管）。工作日内评审在 24 小时内完成。产品负责人为 Sam，Sam 批准范围变更。”

反馈速度值得单独写一行，因为它决定你能多安全地推进。如果利益相关者只能每周评审一次，规范应偏向更小的发布和更少的边缘情况处理。

选择一个与现实相匹配的评审节奏：当日反馈、工作日内 24-48 小时、每周评审会，或（很少见）“无需反馈”。

写出固定的技术约束（栈与托管）

如果不在早期写清技术约束，人们会用假设填补空白。这会让团队在工作开始后重做界面、迁移或更换集成服务。

先说清哪些被锁定，哪些只是偏好。“偏好 React”不同于“必须是 React，因为我们依赖内部组件库”。每个决定用一句话说明即可。

锁定栈（仅写那些确实不能变的）

在整个应用范围内明确：Web、后端、数据库和移动端。如果某部分是灵活的，就说明并给出边界（例如“v1 移动端为 Web 形式”）。

一个简便写法：

• Web/UI： 必须使用 X（理由），或可使用 X/Y（决策所有者）
• 后端： 必须是 X（理由），并以指定风格暴露 API（REST 或 GraphQL）
• 数据库： 必须是 X，以及当前是否需要多租户
• 移动： 必须是原生/Flutter，或“v1 不包含”
• 开发与交付： 是否需要导出源码，以及必需的环境（dev/stage/prod）

然后列出无法避免的集成。指明系统名称（支付、邮件、分析、CRM）并注明硬性限制。例如：“必须使用 Stripe 计费”，“邮件必须通过我们现有的提供方发送”，“分析不得跟踪个人数据”。如果认证已固定（SSO、Google 登录、无密码登录），也要写明。

托管、区域与数据规则（通俗表述）

托管选择会影响架构。写明应用必须在哪里运行以及原因：例如“必须部署在德国”、“数据必须留在欧盟”，或“可以全球部署”。

如果有合规需求，要写具体：保留期限、删除规则和审计需求。

示例： “保存记录 7 年、在经核实请求后 30 天内删除、保留谁查看了记录的审计日志，并且只在患者所在国家部署。” 这些条款可以防止你在准备发布时遇到突发问题。

添加非目标以保护范围

非目标是规范的护栏。它们说明首发不构建、不支持或不追求完善的内容。这是最快减少意外的方法之一，因为很多“小”请求会在后期到来并悄悄改变整个计划。

一个好的非目标应该足够具体，以便团队成员一眼就能识别出范围蔓延。它也应有时间界定。“不在 v1 中”比“我们不会做”更清晰。

首发不构建的内容

从人们常常认为会包含的功能开始。对于一个简单的预约应用，非目标可能包括：

• v1 不做管理门户（仅提供基础员工工具）
• v1 不做多语言或本地化
• 不做离线模式或同步
• 不做复杂仪表盘（仅提供简单的周汇总）
• v1 不做第三方集成（支付、日历、邮件工具）

这些并不是坏功能，而是昂贵的功能。写下来能让首发更聚焦。

还要指出那些会导致连锁工作的“细节”项：角色、权限和边缘工作流。例如“v1 不做自定义角色，仅两种角色：Owner 与 Member。” 这一句能节省数周时间。

不会优化或支持的内容

团队常忘记那些不是功能但会导致返工的非目标。它们在后期显现为痛苦的返工。

决定哪些不做性能调优。例如：“v1 不会针对 100 万用户进行调优，我们假设最多 500 周活跃用户。”

还要说明不支持的测试范围，以便测试目标现实可行：“不支持 Internet Explorer”、“不支持平板专门布局”，或“仅通过邮箱与密码登录（无 SSO，无魔法链接）”。

决定哪些可以变更而不重启整个规范

当规范允许小的决定演进时，团队会觉得更安全。如果只写死不可变的内容，每个新点子都变成争论。一个简短的“可变更”清单给团队空间改进产品而不重启计划。

务实一些。覆盖那些你预期在看到可用版本后会学到的内容，而不是重大的新功能。常见的可变更项包括界面文字、小流程调整、报表列、名称（角色、状态、分类）和基础布局选择。

接着，决定如何接受变更。没有简单的批准规则，“快速调整”会悄悄变成范围蔓延。

一个适合小团队的简单工作流：

• 任何人都可以提出变更，但由一位所有者批准。
• 变更按固定节奏评审（每日或每周）。
• 每个批准的变更以一句话写入规范。
• 若变更影响时间线或成本，必须附带权衡说明。

关键规则：可变更项不得破坏固定约束。如果你的栈是 React + Go + PostgreSQL，则“可变更”请求不能变成“我们要切换后端”。如果截止日期固定，“可变更”不能意味着增加需要两周的新模块。

添加一条大家同意的权衡说明。例如：“如果我们新增一个带自定义权限的用户角色，则把高级报表推到第二阶段。”

可以直接复制到你规范里的逐步格式

好的规范从限制选项开始，而不是扩展它们。这个格式能强制你先写规则再动手构建。

可复制/粘贴格式（填空）

在文档头部使用：

SPEC v0.1 (date)
Owner:
Reviewers:

1) One-liner
- Build: [what it is]
- For: [who]
- So they can: [main benefit]

2) Success definition (3 outcomes)
- Outcome 1: [measurable result]
- Outcome 2: [measurable result]
- Outcome 3: [measurable result]

3) Fixed constraints (cannot change without re-approval)
- Deadline: [date]
- Budget: [$ or hours]
- People: [who is available]
- Tech stack: [fixed choices]
- Hosting/region: [where it must run]

4) Non-goals (must NOT happen)
- [explicit “no”]
- [explicit “not in v1”]
- [explicit “we won’t support”]

5) Open questions
- Q: [question]
  Owner: [name]
  Due: [date]

6) Lock rule
- After review: changes require: [what approval looks like]

（此代码块内容保持原样以便直接使用）

5 步工作流，快速完成规范

1. 先写一句话和三条结果。如果你不能完成这一步，说明你还没准备好决定功能。
2. 接着填写固定约束：截止、预算、团队、栈和托管区域。
3. 添加非目标作为护栏。写下“不做”清单。
4. 列出开放问题，并为每个问题指定负责人。
5. 做一个 15 分钟的评审，然后锁定版本。之后把变更当作新请求来处理，而不是随意修改。

导致后期惊喜的常见陷阱

大多数惊喜不是运气不好，而是规范留有不同解释的空间。

常见陷阱之一是把目标和解决方案混在一起。团队在写下固定（截止、预算、技术栈）和不在范围内的内容前，就直接跳到界面和工作流。结果是漂亮的 UI 计划却无法适配约束。

另一个陷阱是模糊的非目标。“不要额外功能”听起来严格，但当有人要求“再加一个报表”或“做一个快捷的管理面板”时，这并不能保护你。好的非目标要具体且可检验。

隐藏预算或“软”截止日期也是范围炸弹。如果真实预算是 $5k，而规范看起来像 $50k 的产品，团队会做错东西。把尴尬的数字写在页面上。

集成和数据归属也会带来悄然的惊喜。如果你写了“接入 Stripe”但没定义哪些事件、哪些字段以及谁拥有数据，你会一次又一次地回到同样的决定上。

最后一个陷阱是在构建中间改变约束却不说明权衡。把“仅 Web”改为“Web + 移动”，或把“使用 Postgres”改为“使用最便宜的选项”，这些改变都会重塑计划。可以改变，但必须同时更新范围、时间线或质量预期。

避免这些陷阱的快速方法

在规范里加一短段回答五点：

• 什么是固定的（截止、预算范围和谁在构建）
• 技术上什么是固定的（栈、托管、必须的安全规则）
• 明确不包含的内容（3 到 5 个非目标）
• 首发“完成”的含义（一个可度量的结果）
• 哪些变更允许而不需要重开整个规范

在生成任何代码前的快速清单和后续步骤

在任何人开始构建前，你应该能在不翻很长文档的情况下回答“什么是固定？”的问题。

快速检查：

• 能否找到截止、预算范围以及谁有空（或谁没空）来参与构建？
• 技术选择是否写明为固定，并指出有哪些你拒绝使用的东西？
• 托管是否写清，包括区域和简单的数据规则（数据必须放在哪里、何种数据不能跨境）？
• 是否有一份简短的非目标清单来阻止范围蔓延？
• 是否明确哪些可以变更以及谁在不重启规范的情况下批准变更？

如果其中一项缺失，第一个版本仍会被构建，但真正的版本会是第二次重做。

保持节奏而不把自己锁死的下一步：

1. 把约束与非目标放在规范顶部，放在功能前面。
2. 和那些会批准变更的人做一个简短的规划确认。把非目标当面确认，因为沉默往往意味着意见不一致。
3. 用小步迭代构建首个版本，然后随着学习收紧规范。

如果你在使用 Koder.ai (koder.ai)，先在 Planning Mode 中锁定约束与非目标，有助于平台生成匹配你栈、托管区域和范围的首个草案。如果优先级变化，快照和回滚可以在不丢失稳定基线的情况下测试变更，源码导出方便在需要时迁移工作。

当这些规则在早期写下来，关于功能的讨论会更容易，因为每个人都知道哪些必须固定，哪些可以移动。