背景与问题修正
“AI Native 开发模式”这个说法容易变得空泛。如果只把它理解成“用 AI 写更多代码”，很可能会得到更快的技术债、更大的审查压力和更难追溯的生产事故。
更准确的问题应该是：
如何把 AI 作为受控的开发参与者嵌入软件开发生命周期，并用 DevOps 的反馈、自动化、度量、安全和治理机制，让 AI 生成的产出可验证、可追溯、可交付、可运维。
这篇笔记用于持续研究这个问题：如何在软件开发生命周期中同时追求 AI 自动化效率和工程受控性。
资料快照日期：2026-06-30。后续涉及最新报告、工具能力、政策、模型版本或企业实践时，需要重新查证。
核心判断
当前更稳妥的判断是：
- AI 不应被视为替代 SDLC 的捷径，而应被纳入 SDLC 的受控参与者。
- AI 会提高需求整理、代码生成、测试草稿、文档、Review 辅助和运维分析的吞吐量。
- 吞吐提升后，瓶颈会转移到验证、审查、安全、可追溯、权限控制和生产化。
- DevOps 的价值不会因为 AI 降低，反而更重要，因为它提供反馈回路、自动化门禁、交付度量和生产证据。
- AI Native 的成熟度不应看“生成了多少代码”，而应看“AI 产出是否能被持续验证、审查、发布、回滚和审计”。
一句话结论：
AI Native 不是让 AI 绕过工程纪律，而是把 AI 产生的不确定性转化为可验证的软件交付证据。
事实基线
截至本次整理，公开资料给出的方向大致一致：
- DORA 2025 报告强调，AI 更像组织能力的放大器，回报主要来自底层组织系统，而不是工具本身。
- DORA 关于 AI 张力的研究指出，AI 提升吞吐后，可能增加审查、验证和交付稳定性的压力。
- GitHub Octoverse 2025 显示，AI 相关开发活动已经进入主流软件生态，LLM SDK 使用和 agentic coding 迹象明显增长。
- NIST SSDF 要求把安全实践集成进每一种软件开发生命周期。
- NIST AI RMF 和 Generative AI Profile 提醒，AI 系统需要围绕治理、映射、度量和管理风险来设计。
- OWASP LLM Top 10 2025 把 Prompt Injection、敏感信息泄露、供应链、过度代理权等列为核心风险。
- SLSA 和 OpenSSF Scorecard 这类供应链安全实践，正在成为 AI 参与开发后的基础门槛。
这些事实不支持一个简单结论：“AI 越多越好”。它们更支持另一个结论：AI 能力越强，工程控制系统越要强。
AI Native SDLC 框架
可以把 AI Native SDLC 拆成五个关键词：
- Intent：需求、约束、验收标准、风险等级先结构化。
- Context：AI 能访问受控的代码、文档、接口、日志、架构决策和规范。
- Agent：AI 可以生成、修改、测试、审查、总结，但权限分级、行为可审计。
- Evidence：每个产出都必须有测试、扫描、评审、运行证据支撑。
- Governance：人负责判断，流水线负责验证，平台负责权限和追踪。
需求阶段
AI 适合做：
- 汇总用户反馈、issue、客服记录、事故记录和日志摘要。
- 把自然语言想法转成用户故事、验收标准、边界条件和风险清单。
- 对需求提出反例，例如权限、数据一致性、异常流、灰度发布、回滚方案。
控制点：
- 需求不能停留在 prompt。
- 必须沉淀为 PRD、用户故事、验收标准、接口契约或 issue。
- 关键需求必须明确非功能要求，例如安全、性能、可观测性、合规、兼容性和回滚。
设计阶段
AI 适合做：
- 生成 ADR 备选方案。
- 草拟接口、数据流、状态机、错误处理和威胁模型。
- 对比不同架构方案的代价。
- 检查方案是否遗漏安全、降级、可观测、迁移、回滚和运维入口。
控制点：
- 人类架构师或负责人必须做最终取舍。
- AI 生成的设计不能直接成为事实，必须经过约束核查。
- 架构决策要留下 ADR 或设计记录，避免未来只剩一段聊天记录。
编码阶段
AI 适合做：
- 生成样板代码。
- 小范围重构。
- 根据既有模式补全实现。
- 生成单测草稿、mock、迁移脚本、CLI 工具和文档。
- 解释陌生代码和调用链。
控制点：
- PR 要小。
- 强类型、lint、format、单测、集成测试必须进入默认流程。
- AI 生成代码不能绕过代码审查。
- 对安全、权限、支付、生产数据、基础设施、机器人或工业设备控制相关代码，应提高审查等级。
Review 阶段
AI 适合做：
- 在作者侧提前检查代码风格、测试缺口、潜在 bug 和安全风险。
- 总结 PR 变更范围。
- 对比需求验收标准和实际实现。
- 提醒破坏性变更、迁移风险和回滚遗漏。
控制点：
- AI Review 不能替代人工 Review。
- 人工 Review 应聚焦语义正确性、业务后果、架构一致性和风险判断。
- 不应把 AI 接受率、AI 评论数量或代码行数当作质量指标。
测试阶段
AI 适合做：
- 生成测试用例草稿。
- 补充边界条件。
- 生成 e2e 脚本、契约测试、mock 数据和回归用例。
- 从事故复盘中提炼回归测试。
控制点：
- 不能让“AI 生成代码 + AI 生成测试”自证正确。
- 关键路径的测试 oracle 必须由人或明确规格定义。
- CI 至少覆盖单测、集成测试、契约测试、e2e、静态检查和安全扫描中的必要部分。
DevSecOps 阶段
AI 时代应把这些能力作为默认门禁：
- SAST：静态应用安全测试。
- SCA：开源依赖和漏洞扫描。
- secret scanning：密钥泄漏扫描。
- IaC scanning：基础设施即代码扫描。
- container scanning：镜像漏洞扫描。
- SBOM：软件物料清单。
- provenance：构建来源和制品可追溯。
- signed artifact：制品签名。
- policy as code：用规则控制发布、权限和例外。
控制点：
- AI 生成代码进入同一质量门禁。
- 不能为 AI 代码开“快速通道”。
- 例外必须记录原因、负责人、过期时间和补偿措施。
发布阶段
AI 适合做：
- 生成 release note。
- 总结变更影响。
- 草拟回滚预案。
- 分析灰度数据和错误趋势。
控制点：
- 发布仍应依赖 feature flag、canary、blue-green、自动回滚和审计记录。
- 高风险发布必须有人审批。
- AI 可以建议操作，但不应直接绕过流水线变更生产环境。
运维阶段
AI 适合做：
- 日志摘要。
- 告警聚类。
- runbook 推荐。
- 事故复盘草稿。
- 根因假设生成。
- 用户影响范围分析。
控制点：
- 对生产写操作、删数据、扩缩容、权限变更、设备控制等动作，应默认 human-in-the-loop。
- AI 的操作建议要进入审计。
- 事故复盘要区分事实、推断和行动项。
自动化与受控的边界
可以先按风险等级划分 AI 权限：
| 场景 | 推荐自动化程度 | 控制要求 |
|---|---|---|
| 文档摘要、代码解释、测试草稿 | 高 | 保留来源和人工抽查 |
| 样板代码、小型重构、非关键工具 | 中高 | 小 PR、CI、Review |
| 业务核心逻辑、权限、安全、支付 | 中低 | 强制人工审查、测试证据 |
| 基础设施、生产发布、数据迁移 | 低 | 审批、回滚、审计 |
| 删除生产数据、控制真实设备、改变权限边界 | 极低 | 默认禁止自动执行，必须人工确认 |
一个实用原则：
AI 可以加速低风险、可回滚、可测试的事情；越接近生产状态、真实资产和不可逆操作，越需要人和平台门禁。
度量体系
保留 DevOps 的核心指标：
- lead time：从提交到上线的时间。
- deployment frequency：部署频率。
- change failure rate：变更失败率。
- MTTR：平均恢复时间。
增加 AI 时代指标：
- AI 代码返工率。
- AI 产出缺陷逃逸率。
- AI 参与 PR 的平均 Review 时长。
- PR 体积变化。
- 关键路径测试覆盖率。
- CI 阻断原因分布。
- SAST/SCA/secret scanning 阻断数。
- SBOM 覆盖率。
- 制品签名覆盖率。
- provenance 覆盖率。
- agent 权限违规次数。
- 生产事故中 AI 参与代码的比例和原因。
谨慎使用这些指标：
- AI 生成代码行数。
- Copilot/Cursor/Claude Code 接受率。
- prompt 次数。
- commit 数。
- PR 数量。
这些指标可能说明活跃度，但不能直接说明软件质量和交付价值。
实践路线
2 到 4 周：建立基线
目标：知道当前工程系统的真实状态。
交付物：
- 当前 DORA 指标快照。
- Review 时长和 PR 体积统计。
- CI 失败原因分类。
- 缺陷逃逸和回滚记录。
- AI 使用规范初稿。
验收标准：
- 明确哪些场景允许 AI 参与。
- 明确哪些数据不能进入外部模型。
- 明确哪些操作必须人工审批。
- 至少有一条从需求到发布的证据链样例。
1 到 2 个月：受控试点
目标：选一个低风险项目，把 AI 纳入完整 SDLC。
适合试点的对象：
- 内部工具。
- 非核心服务。
- 文档和测试补全。
- 可回滚的小功能。
交付物：
- AI 辅助需求、设计、编码、测试、Review、发布的完整样例。
- CI/CD 门禁。
- 安全扫描。
- PR 模板。
- Review checklist。
- 发布记录和回滚方案。
验收标准：
- AI 参与的 PR 能通过统一门禁。
- 人工 Review 负担没有失控。
- 缺陷没有明显上升。
- 产出可以被追溯到需求、测试和发布记录。
3 到 6 个月：建设 AI Engineering Platform
目标：让 AI 使用从个人技巧变成组织能力。
交付物：
- 代码知识库和文档索引。
- 规范库和 prompt 模板。
- agent 权限模型。
- 审计日志。
- 制品 provenance。
- AI 使用成本和质量仪表盘。
- 安全和合规策略。
验收标准：
- 不同团队可以复用同一套 AI 工程规范。
- AI 产出可审查、可追溯、可度量。
- 高风险动作默认受控。
- 平台能回答：谁让 AI 做了什么、用了什么上下文、改了什么、如何验证、何时发布、出了问题如何回滚。
与个人技术方向的关系
对我这种从 Web/full-stack 向工业软件、机器人应用、数字孪生和 AI-assisted operations 转型的人来说，这个方向有现实价值。
更强的定位不是“我会用 AI 写代码”，而是：
我能把 AI、DevOps、工业系统状态、可观测性、权限控制和人机协同流程结合起来，构建可交付、可追溯、可运维的智能软件系统。
这和工业机器人、机器视觉、数字孪生、设备状态平台、AI 运维助手都有连接点。尤其在真实设备和工业现场中，自动化不能脱离状态建模、权限、安全、审计、回滚和人工确认。
后续研究问题
后续需要继续研究：
- 企业如何定义 AI 生成代码的责任边界。
- AI agent 在 CI/CD 中应获得哪些最小权限。
- 如何设计 agent 审计日志和 evidence trail。
- AI Review 如何避免制造噪音。
- AI 生成测试如何和人工定义的 oracle 结合。
- 如何把 NIST SSDF、SLSA、OWASP LLM Top 10 落到日常开发流水线。
- 如何在工业软件和机器人系统中设计 human-in-the-loop。
- 如何度量 AI 对质量、交付速度和运维稳定性的真实影响。
持续研究日志
2026-06-30：初始判断
初始结论：AI Native 开发不应被理解成“AI 替代软件工程”，而应被理解成“AI 参与软件工程后，如何通过 SDLC、DevOps、DevSecOps 和治理机制把不确定产出变成可信交付”。
当前最重要的实践问题不是 prompt，而是：
- 上下文如何受控。
- 权限如何分级。
- 产出如何验证。
- 证据如何保留。
- 事故如何追溯。
- 生产如何回滚。
参考资料
- DORA, 2025 State of DevOps Report: https://dora.dev/research/2025/dora-report/
- DORA, Balancing the Tensions of Speed and Stability in AI-assisted Software Development: https://dora.dev/insights/balancing-ai-tensions/
- GitHub Octoverse 2025: https://github.blog/news-insights/octoverse/
- NIST Secure Software Development Framework, SP 800-218: https://csrc.nist.gov/pubs/sp/800/218/final
- NIST AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
- OWASP Top 10 for LLM Applications 2025: https://genai.owasp.org/llm-top-10/
- SLSA: https://slsa.dev/
- OpenSSF Scorecard: https://scorecard.dev/
