与 AI 交流 AI

软件工程产品研发SOP

41分钟阅读

软件工程产品研发 SOP：从拿到需求到完成产品

软件工程不是”把代码写出来”，而是把一个模糊需求变成可验证、可交付、可维护、可迭代的产品。
最科学的流程不是靠灵感冲刺，而是建立一条完整证据链：每一步都有输入、输出、决策依据和验收证据。

一句话总览

产品研发 = 需求判断 + 设计定稿 + 分步实现 + 自动验证 + 真实验收 + 上线反馈。

如果只记一句话：

不要从”写代码”开始，要从”这件事值不值得做、做成什么样才算完成、用什么证据证明完成”开始。

全流程地图

可以把研发过程想成一条从”想法矿石”到”成品机器”的流水线：

需求输入
  ↓
0. 价值判断：要不要做？是不是该自研？
  ↓
1. 需求澄清：谁用？解决什么问题？边界是什么？
  ↓
2. 产品 Spec：页面、流程、权限、状态、验收标准
  ↓
3. 技术设计：架构、数据模型、接口、安全、部署
  ↓
4. 实施计划：拆任务、排顺序、定义测试与提交点
  ↓
5. TDD 开发：先写失败测试，再写最小实现
  ↓
6. 质量门禁：单测 / 集成 / E2E / lint / typecheck / build
  ↓
7. 验收发布：按角色跑真实流程，上线、回滚、监控
  ↓
8. 反馈迭代：真实用户数据 → 下一轮需求判断

这条链路里任何一步缺失，都会变成后面更贵的返工。

缺哪一步常见后果
不做价值判断花几个月做了一个其实该用低代码的内部工具
不做需求澄清开发中途不断改口径，所有人都觉得”对方没说清楚”
不写验收标准产品做完后无法判断是否完成，只能靠感觉吵架
不做技术设计数据模型、权限、状态流转后期返工成本极高
不写实施计划写到哪算哪，容易漏掉边界、测试、部署
不做测试驱动改一个地方坏三个地方，靠人工点页面救火
不做质量门禁本地能跑，线上崩；一个小改动带出大事故
不做上线反馈上线后没人用、用错、慢慢腐烂，都没人知道

阶段 0：需求进入前，先判断要不要做

老板、客户、朋友说”做个系统”，第一反应不要是”用 Vue 还是 React”，而是问：

这到底是值得自研的产品，还是应该先用现成工具验证的内部流程？

0.1 三个核心问题

问题目的
谁用？内部员工、外部客户、管理者、运营人员，决定产品形态
为什么现在要做？是真痛点、老板灵感、竞品压力，还是临时管理需求
不做会怎样？判断优先级和投入上限

0.2 四种处理方式

处理方式适合场景输出
不做价值不明确、用户很少、替代方案够用记录原因，避免反复讨论
用 SaaS / 低代码内部表单、审批、工单、CRM、巡检2-4 周验证流程
做 PoC技术不确定、AI / 算法 / 性能风险高验证核心可行性
做产品化自研用户清晰、流程稳定、数据资产重要进入正式研发流程

0.3 内部工具的特殊判断

内部工具最容易误判：看起来像”做个 App”，本质上可能只是”员工填表 + 流程流转 + 权限控制”。

用户 ≤ 30 人
+ 流程还在变化
+ 核心是表单 / 审批 / 工单 / 看板
+ UI 不需要强品牌体验
  ↓
优先低代码，不要直接自研

这部分可以直接参考 内部工具选型方法论：它讲的是要不要自研，本文讲的是确定要做之后怎么研发。

阶段 1：需求澄清与业务建模

需求澄清不是”把客户的话抄一遍”，而是把自然语言翻译成工程能实现的模型。

1.1 需求澄清五件套

维度要问的问题产物
用户谁在什么场景下用？角色清单
目标用户完成什么任务？用户故事 / 流程图
数据需要记录哪些对象？实体清单
状态每个对象怎么流转？状态机
规则哪些能做、不能做、必须做？业务规则表

1.2 从”功能列表”变成”业务对象”

差的需求：

我要一个维修管理功能。

好的业务建模：

对象：维修工单
角色：前台 / 维修师傅 / 保洁 / 店长
状态：待分配 → 待接单 → 处理中 → 待核查 → 已完成 / 已驳回
关键字段：房间、问题描述、图片、负责人、截止时间、核查签字
权限：前台可登记，维修师傅只能处理分配给自己的工单，店长可看全部
验收：能完整跑通登记 → 分配 → 接单 → 完成 → 核查签字

1.3 业务建模的三个图

图解决什么问题例子
角色-权限矩阵谁能看、谁能改、谁不能碰管理员 / 前台 / 维修 / 财务
状态机对象从生到死怎么流转工单、订单、审批单
数据关系图哪些表 / 对象互相关联用户、房间、工单、附件

1.4 澄清阶段的退出标准

只有满足这些条件，才进入产品 Spec：

  • 每个核心角色都有明确使用场景
  • 每个核心对象都有状态流转
  • 每条关键业务规则能写成”如果 A，则 B”
  • 至少列出 5-10 条验收场景
  • 明确哪些功能本阶段不做

1.5 需求变更与拒绝机制

需求澄清结束后，最怕的不是”还有问题没问清”，而是业务方一句”我又想到一个功能”直接打穿计划。
所以澄清阶段必须产出一个需求基线：当前版本做什么、不做什么、验收按什么标准来。

基线不是为了拒绝沟通，而是为了拒绝”免费、立刻、无代价”的变更。

变更分级

类型判断标准处理方式
口径澄清不改变字段、流程、权限、验收，只是把一句话说清楚直接补进 Spec，并标记澄清记录
小变更影响小于 0.5 天，不改数据模型，不影响关键路径可进入当前迭代，但必须写入变更记录
中变更影响 0.5-2 天，涉及页面、接口、测试用例调整只能用”替换同等工作量需求”或”顺延交付”进入当前迭代
大变更影响超过 2 天，涉及数据模型、权限、安全、状态机、第三方接口进入下一迭代或重新评审，不能口头插队
红线变更破坏合规、安全、数据一致性、核心体验技术负责人有权否决，除非业务负责人书面接受风险

变更处理流程

业务方提出变更
  ↓
记录原话：谁、何时、想改什么、为什么
  ↓
评估影响：范围 / 工期 / 成本 / 风险 / 测试 / 上线时间
  ↓
给 3 个选项：
  A. 本期不做，进入需求池
  B. 本期做，但替换掉同等工作量的需求
  C. 本期做，同时顺延交付时间
  ↓
有权人拍板
  ↓
更新 Spec / Plan / 验收清单

谁有权拍板

决策拍板人
要不要做业务负责人 / 产品负责人
怎么做技术负责人
本期做还是下期做产品负责人 + 技术负责人共同决定
是否接受延期 / 加预算项目负责人 / 付费方
是否突破安全和合规红线默认不能突破；必须业务负责人书面确认风险

拒绝不合理需求的话术

拒绝不是说”不行”，而是把真实代价摆出来：

这个需求本身可以做，但它会影响当前基线。
如果放进本期，有三个选择：
1. 替换掉 A 功能
2. 交付时间顺延 3 天
3. 放入下一期
 
我不建议直接插入，因为它会影响已经确认的验收范围和测试计划。

这套话术的关键是：不否定业务价值，只拒绝无成本插队。

阶段 2：产品 Spec 与验收标准

Spec 是研发的合同。它不是越厚越好，而是要把”做成什么样”写到可以验收。

2.1 Spec 应该包含什么

模块内容
背景与目标为什么做，解决什么问题
范围本阶段做什么、不做什么
角色与权限谁能访问哪些页面、字段、动作
页面与流程用户如何完成关键任务
数据字段每个对象有哪些字段、校验规则
状态流转状态、触发动作、异常分支
通知规则何时通知谁，通过什么通道
验收标准具体到可测试的场景

2.2 好验收标准的格式

差的验收标准：

维修模块能正常使用。

好的验收标准：

前台创建维修工单，选择房间、问题类型、截止时间并上传图片后：
1. 工单状态为"待分配"
2. 店长能在工单列表看到该记录
3. 维修师傅在未分配前看不到该工单
4. 后端返回的工单详情不包含无权限字段

2.3 Spec 的风险清单

每份 Spec 都应该有风险表：

风险为什么危险应对
需求一次性太大团队消化不了，上线失败拆 MVP / 阶段 2 / 阶段 3
权限粒度太粗敏感信息泄露做字段级权限
平台能力限制小程序、浏览器、第三方接口有限制写入技术约束
附件和数据膨胀服务器磁盘和带宽爆炸上对象存储和归档策略
验收标准模糊做完无法判断成败改成可测试场景

阶段 3：技术选型与架构设计

技术设计的目标不是炫技，而是让系统能以合理成本长期运行。

3.1 技术选型的五个维度

维度要问的问题
业务匹配这个技术能不能自然表达业务模型？
团队能力现在的人会不会维护？
生态成熟文档、社区、组件、运维工具是否成熟？
成本开发成本、服务器成本、学习成本、迁移成本
风险安全、合规、平台限制、供应商锁定

3.2 架构设计要覆盖的内容

设计项典型产物
系统架构前端、后端、数据库、缓存、对象存储、推送通道
模块边界auth / users / orders / repair / dashboard
数据模型ER 图、索引、唯一约束、软删除策略
API 契约REST / GraphQL / OpenAPI、错误码、分页、鉴权
权限模型RBAC、ABAC、字段级权限
异常处理错误返回格式、重试、幂等、冲突处理
部署架构Docker、Nginx、HTTPS、备份、监控

更细的架构原则可以接着读 软件架构设计详解。

3.3 架构阶段最常见的错

错误表现修正
过度设计5 人内部系统上微服务、K8s、分库分表从单体 + 清晰模块边界开始
忽略权限只做登录，不做数据范围和字段权限需求阶段就建角色权限矩阵
忽略数据迁移直接改表，线上数据无法升级用迁移工具管理 schema
忽略附件图片视频存在本机用 OSS / S3 类对象存储
忽略观测线上出问题只能猜日志、指标、健康检查先设计

阶段 4：实施计划与任务拆分

Plan 是把 Spec 变成可执行动作。好的计划像施工图，差的计划像口号。

4.1 任务拆分原则

原则解释
小步提交每个任务 0.5-2 天内能完成
垂直切片尽量从 UI 到 API 到 DB 打通一个小闭环
先核心后边角先状态机、权限、数据，再做导出、报表、皮肤
先风险后舒适区先验证第三方接口、性能、权限等高风险项
每步有测试没有测试的任务，不算工程任务

4.2 时间估算方法

估算不是猜日期，而是用已知任务当尺子，衡量未知任务的相对复杂度。

先找锚点任务

锚点任务是团队做过、风险低、边界清楚的任务：

锚点典型耗时特征
简单字段新增0.5 天有现成表单、API、测试，只加字段和校验
标准 CRUD 页面1 天能参考已有列表 / 详情 / 编辑页
标准 API + 集成测试1 天数据模型清楚，权限规则简单
一个状态机分支1-2 天有已有状态机结构，只新增一条合法流转
第三方接口首次接入2-5 天文档、鉴权、回调、异常都不确定

如果一个任务没有参考代码、没有明确验收、依赖外部平台，就不要直接估 1 天。先做 Spike。

用倍率估算

有参考代码 + 有测试 + 数据模型不变 = 1 倍
有参考代码 + 要改 API / 页面 / 测试 = 1.5 倍
没有参考代码 + 业务规则清楚 = 2 倍
涉及权限 / 状态机 / 金额 / 数据迁移 = 2-3 倍
涉及第三方接口 / 性能 / 合规 / 小程序审核 = 3-5 倍

例子：

已有"维修列表"，现在做"整改列表"：
- 页面结构类似：1 倍
- API 字段略有不同：+0.5 倍
- 权限类似：不额外加
估算：1-1.5 天
 
新增"微信订阅消息真实推送"：
- 第三方模板申请：不确定
- 小程序端授权：不确定
- 后端通道：有 PushService 可参考
估算：先做 0.5-1 天 Spike，确认限制后再估正式实现

Spike：专门给不确定性估时

Spike 不是正式开发，而是限时探路：

场景Spike 目标
第三方接口文档不清跑通最小请求，确认鉴权、字段、错误码
性能风险用假数据压测，确认数量级
UI 交互没把握做一个低保真原型，让业务方确认
数据迁移风险在测试库演练迁移和回滚

Spike 必须限时，一般 0.5-2 天。结束后只输出结论：

可行 / 不可行 / 需要替代方案
正式实现估时
主要风险

估算要给区间，不给单点

不要说：

这个 3 天做完。

要说：

乐观 2 天，正常 3 天，悲观 5 天。
前提是微信模板今天能申请下来；如果模板审核卡住，交付时间不算在开发估算内。

估算的本质是管理不确定性，不是签军令状。

4.3 实施计划的标准格式

任务 1：建立维修工单状态机
输入：Spec 中的维修状态流转表
改动：state_machine.py / test_state_machine.py
测试：非法状态转换必须失败；合法转换必须成功
完成证据：pytest 指定用例通过
 
任务 2：实现创建工单 API
输入：维修工单字段定义
改动：models.py / schemas.py / router.py / service.py
测试：权限、字段校验、创建成功、无权限失败
完成证据：集成测试通过 + OpenAPI 可见

4.4 任务顺序推荐

1. 数据模型和迁移
2. 领域规则 / 状态机
3. 后端服务与 API
4. 权限与安全边界
5. 前端页面和交互
6. 通知、附件、异步任务
7. E2E 真实流程
8. 部署和运维脚本

阶段 5：测试驱动开发

TDD 的核心不是”测试多一点”，而是：

先证明测试能抓住问题，再写最少代码让它通过。

5.1 红绿重构

RED：写一个失败测试
  ↓
确认失败原因正确
  ↓
GREEN：写最小实现
  ↓
确认测试通过
  ↓
REFACTOR：清理结构，保持测试通过

5.2 哪些东西最应该 TDD

类型为什么
权限错一次就是数据泄露
状态机非法流转容易藏 bug
价格 / 金额 / 库存业务损失直接发生
API schema前后端契约一变就坏
数据迁移线上数据不可随便试
工具函数小函数被很多地方复用

5.3 测试分层

单元测试：测一个函数 / 状态机 / 权限判断
  ↓
集成测试：测 API + 数据库 + 权限
  ↓
E2E 测试：像真实用户一样点完整流程
  ↓
手工验收：业务角色按清单跑关键场景
层级特点不适合承担什么
单元测试快、准、定位清楚不证明系统整体能用
集成测试能发现模块连接问题不证明 UI 体验
E2E最接近真实用户不适合覆盖所有边界
手工验收能发现流程和认知问题不该替代自动化测试

💡 前端落地：上面”单元 / 集成 / E2E”这几层在前端具体用什么工具（Vitest / Testing Library / Playwright）跑、.spec 文件怎么命名，见 前端测试栈速查。

阶段 6：质量门禁与自动化验证

质量门禁就是”不达标不能合并 / 不能发布”。

6.1 基础门禁

门禁目的
format代码风格统一，减少无意义 diff
lint抓明显错误和坏味道
typecheck提前发现类型契约错误
unit test保证核心函数行为
integration test保证 API / DB / 权限连通
e2e test保证关键用户流程
build保证能生成可部署产物
migration check保证数据库升级可执行

6.2 CI/CD 的位置

CI/CD 不是”高级运维玩具”，而是把质量门禁自动化。

开发者 push
  ↓
CI 自动拉代码
  ↓
安装依赖
  ↓
lint / typecheck / test / build
  ↓
全部通过才允许合并
  ↓
CD 构建产物并部署到测试 / 生产环境

完整机制可以参考 CD 与 GitHub Actions。

6.3 完成声明必须有证据

不要说：

应该好了。

要说：

已运行：
- backend pytest：152 passed
- frontend typecheck：passed
- e2e repair workflow：passed
- docker build：exit 0
 
剩余风险：
- 真实 OSS 上传未验证，因为当前环境没有生产 AK/SK

这不是形式主义，而是防止”看起来完成”。

阶段 7：上线、回滚、监控

上线不是最后一步，而是产品第一次接触真实世界。

7.1 上线前检查表

检查项证据
数据库已备份备份文件路径 / 恢复演练记录
迁移可执行migration 命令 exit 0
环境变量完整.env.example 与生产配置逐项对照
HTTPS 可用浏览器 / curl 验证
健康检查可用/health 返回 OK
日志可查能按 request_id 找到请求
回滚方案存在上一版本镜像 / tag / 数据库回滚策略
关键流程验收角色清单逐项通过

7.2 发布策略

策略适合场景风险
直接发布内部小系统、低并发、可快速回滚出问题影响所有人
灰度发布有用户分组、有监控能力需要路由 / 开关支持
蓝绿发布不能长时间停机的服务资源成本更高
金丝雀发布大规模系统逐步放量运维复杂度高

7.3 监控三层

系统层：CPU / 内存 / 磁盘 / 网络
应用层：接口耗时 / 错误率 / 队列堆积 / 任务失败
业务层：注册数 / 下单数 / 工单完成率 / 超时率

技术指标告诉你”机器有没有坏”，业务指标告诉你”产品有没有真的工作”。

7.4 上线后快速验证节奏

上线后的第一天，不要发布完就走。要安排一个上线守护窗口，有人盯日志、盯指标、盯业务流程。

上线后 30 分钟

目标：确认系统没有立刻炸。

检查谁看异常决策
服务是否能访问，健康检查是否 OK技术负责人健康检查失败，立即回滚
错误率是否明显上升后端 / 运维5xx 连续 5 分钟异常，暂停放量
登录、创建、提交等核心流程能否跑通产品 / 测试核心流程不可用，立即回滚
数据库迁移后关键表是否可读写后端写入失败，停止使用并回滚
日志里是否有大量同类异常后端同类异常持续出现，进入故障处理

上线后 2 小时

目标：确认真实用户开始使用后没有业务异常。

检查谁看异常决策
核心业务量是否接近日常水平产品 / 运营业务量断崖下降，排查入口和权限
关键转化是否卡住产品某一步骤大量退出，优先热修或降级
任务队列 / 推送 / 定时任务是否堆积后端堆积持续增长，暂停相关功能
客服 / 员工反馈是否集中在同一问题业务负责人同一问题超过 3 次，升级为 P1/P0
监控指标是否稳定技术负责人指标恶化但业务可用，准备修复方案

上线后 24 小时

目标：判断版本是否稳定，是否进入常规维护。

检查谁看决策
P0/P1 故障数量项目负责人有 P0 必须复盘；P1 超过 2 个不继续发新功能
用户反馈和工单产品 / 业务负责人归类为 bug、体验问题、下一期需求
性能趋势技术负责人慢接口进入优化列表
数据一致性后端 / 数据负责人抽查关键数据，发现异常立刻修复
回滚点是否仍保留运维保留到下一个稳定版本

回滚、热修、继续观察怎么选

情况决策
核心流程不可用、数据写错、安全泄露立即回滚
单个非核心页面报错，有替代路径热修
指标轻微波动，业务未受影响继续观察，设定复查时间
第三方服务异常导致局部功能失败降级或关闭该功能

上线守护窗口结束前，要留一条发布记录：

版本号：
上线时间：
变更范围：
30 分钟检查结果：
2 小时检查结果：
24 小时检查结果：
遗留问题：
是否进入常规维护：

阶段 8：真实用户反馈与下一轮迭代

MVP 不是”缩水版终点”，而是学习工具。

8.1 上线后要收集什么

数据作用
哪些功能没人用删除或延后，不要继续投入
哪些流程卡住优先优化真实摩擦点
哪些字段总填错字段设计或文案有问题
哪些权限经常申请角色模型可能错了
哪些 bug 高频出现进入下一轮质量改进

8.2 反馈进入下一轮研发

线上反馈
  ↓
问题分级：P0 / P1 / P2 / P3
  ↓
需求复盘：是真需求还是个别抱怨？
  ↓
更新 Spec
  ↓
更新测试
  ↓
进入下一轮迭代

8.3 问题分级标准

P0/P1/P2/P3 不只是标签，它决定响应速度、负责人和是否打断当前计划。

等级定义例子响应要求
P0核心业务不可用、数据损坏、安全泄露、无法登录、无法提交关键单据全员无法登录；维修工单创建失败；敏感字段泄露立即响应，2 小时内给处理结论；必要时回滚
P1核心流程部分受影响，但有临时绕行方案上传附件失败但可先保存文字；部分角色看不到应看的列表当天响应，24 小时内修复或给替代方案
P2非核心功能异常、体验明显影响效率筛选条件不记忆；列表加载慢；提示文案误导进入本周 / 下个迭代
P3优化建议、低频问题、视觉细节、未来想法想加导出格式；按钮位置优化；新增统计维度进入需求池，定期评审

分级时先看影响面

同一个 bug，在不同影响面下等级不同：

影响面升级规则
影响所有用户至少 P1，核心流程则 P0
只影响单个角色看该角色是否能完成核心任务
只影响单个用户默认 P2/P3，除非涉及数据或安全
影响数据正确性至少 P1，已经写错数据则 P0
影响安全 / 权限直接 P0

问题处理模板

问题标题：
发现时间：
影响范围：
当前等级：P0/P1/P2/P3
复现步骤：
临时绕行方案：
负责人：
预计下一次更新：
最终处理结果：
是否需要复盘：

P0/P1 必须有负责人和下一次更新时间；没有负责人，就等于没人处理。

8.4 迭代不是无限加功能

每轮迭代都要问：

  • 这个功能解决了哪个真实问题？
  • 有没有更便宜的运营 / 流程 / 配置方案？
  • 做完后用什么指标证明有效？
  • 会不会让现有用户更难用？
  • 是否值得增加长期维护成本？

AI 协作下的工程 SOP

AI 能极大提高研发速度，但也会放大”表演性完成”风险：它能写出很像完成报告的文字，却未必真的跑过验证。

AI 参与研发时的正确分工

阶段AI 适合做人必须把关
需求澄清整理问题、提炼角色、发现矛盾判断业务真实优先级
Spec草拟结构、补边界、写验收标准确认范围与取舍
架构给方案、列风险、做对比拍板技术栈和成本
编码执行小任务、补测试、改 bug审查关键设计和安全
验证跑命令、读日志、整理证据判断证据是否足够
发布生成 checklist、检查配置控制生产权限和回滚

防止 AI “看起来完成”的 5 条规则

规则做法
每个任务先写完成证据没有证据的任务不准开始
让 AI 贴命令和结果不接受”应该可以”
大任务拆小每个小任务能独立验证
关键路径人工复核权限、金额、数据迁移、发布
保留真实验收清单最终以业务流程跑通为准

这部分和 LLM 典型失败模式 是同一条思想：讲得像完成，不等于真的完成。

用当前民宿运营系统做一次映射

以”民宿运营管理系统”为例，科学研发流程应该这样映射：

阶段在该项目里的产物
价值判断先判断这是内部 OA / 工单系统，不是 C 端 App
范围切分MVP 做登录、房间、维修、整改、首页、推送；发票 / 水电气 / 房租放阶段 2
Spec需求规格、技术架构、数据模型、API、UI、权限、测试文档
架构FastAPI + PostgreSQL + Redis + uni-app + Docker Compose
计划W1-W8 分阶段完成报告
TDD后端 unit / integration tests，前端工具函数测试
E2EPlaywright 覆盖登录、房间、维修、整改、通知
验收MVP 验收清单按角色跑真实流程
发布DEPLOY 文档、Docker、Nginx、备份脚本
反馈阶段 2/3 根据真实使用情况继续排期

关键不是这套技术栈本身，而是它体现了一个原则：

每个工程决策都能追溯到业务风险，每个完成声明都能落到测试或验收证据。

每阶段输入 / 输出 / 验收证据速查

阶段输入输出验收证据
0 价值判断原始想法 / 业务痛点做 / 不做 / 低代码 / PoC / 自研决策决策表 + 成本估算
1 需求澄清访谈 / PDF / 口述需求角色、流程、对象、规则、需求基线、变更规则业务方确认无重大遗漏；变更有记录和拍板人
2 产品 Spec澄清结果页面、流程、字段、状态、验收标准每条需求有可测场景
3 技术设计Spec架构、数据模型、API、权限、部署方案风险表 + 技术取舍说明
4 实施计划Spec + 架构任务清单、文件清单、测试计划、估算区间、Spike 结论每个任务有完成证据；高不确定任务先探路
5 TDD 开发计划任务测试 + 实现 + 小提交红绿重构记录 / 测试通过
6 质量门禁代码变更CI、测试、构建、检查结果全量门禁通过
7 上线发布可部署产物生产版本、部署记录、回滚点、上线守护记录健康检查 + 验收清单 + 30 分钟 / 2 小时 / 24 小时检查
8 反馈迭代真实使用数据下一轮需求池、P0-P3 问题清单指标 / 用户反馈 / 缺陷分级 / 响应记录

30 秒口令版

先定性：该不该做、要不要自研
再澄清：谁用、做什么、边界在哪
锁基线：变更要记录、评估、拍板
写 Spec：页面、流程、数据、权限、验收
做设计：架构、模型、接口、安全、部署
拆计划：小任务、估区间、测试先行、逐步提交
写代码：红绿重构，不靠感觉
跑门禁：lint / typecheck / test / build / e2e
再验收：按真实角色跑流程
才上线：备份、迁移、健康检查、回滚、守护 24 小时
看反馈：P0-P3 分级，数据说话，进入下一轮

与本知识库其他章节的关联

一句话总结

科学的软件工程流程，本质是把”我觉得做完了”变成”证据证明它满足需求、能上线、能维护、能继续迭代”。

创建时间：2026-05-28。源自民宿运营管理系统从需求评估、工程设计、MVP 实现到验收清单的完整实践复盘；本文定位为 05_技术基础 下的软件工程产品研发总纲。

来源与局限性

来源

  • 本文在正文/文末已有的出处与时间标记：
    • 创建时间：2026-05-28。源自民宿运营管理系统从需求评估、工程设计、MVP 实现到验收清单的完整实践复盘；本文定位为 05_技术基础 下的软件工程产品研发总纲
  • 除上述外未标注其他外部出处；本知识库内容主要来自与 AI 的多轮交流沉淀（见项目 CLAUDE.md 的定位说明）。

本节由脚本依据正文的出处标记自动归纳，未经逐句人工复核。下表只陈述可统计的客观事实，不代表对内容质量的判断；如与正文冲突，以正文为准。

局限性

维度客观情况
时效性含约 37 处具体版本号/型号表述；文件最后修改于 2026-06-14——版本与价格类信息变动快，引用前请核对当前情况
覆盖范围全文约 14k 字，覆盖范围以正文目录为准，未展开的边界情况请另行查证
实战验证正文含约 1 处实测/复现/踩坑类表述（自动统计，仅供参考；具体哪些结论经过动手验证需读正文判断）

最后更新：2026-06-14（据 git 提交历史回填，非内容重新审校日期）

关系图谱

反向链接