- Authors
- Name
- IronRookieCoder
近半年AI-Native工作感受与思考
AI-Native：用AI改变开发模式，加速业务发展。
2025 年下半年，我的主要工作围绕 AI-Native 的探索、落地实践和推广展开。借这个机会，对近半年的工作进行了一次系统复盘。这段经历让我对AI Native如何融入研发全流程、真正产生实际价值，形成了一些认知，核心感受从以下维度展开。
AI 融入开发流程，是效能落地的前提
在实践中我逐渐意识到，AI 与业务的结合，并不是简单地把 AI 叠加到原有流程上，也不是推翻既有的研发模式（需求 → 设计 → 开发 → 测试 → 部署）。更现实、也更有效的方式，是在这套已经被验证过的流程中，逐个环节引入 AI 能力，解决具体问题，从而实现整体效率的提升。
这一点在 SDD 流程的搭建过程中体会尤为明显。从内部业务平台内部的孵化试点，到逐步推广成体系化的 SDD 流程；从 SPEC 规范的建设，到 AI原生开发工具套件对SPEC的统一管理，再到通过 MCP 将 AI 能力接入代码托管平台、内部协作平台、测试管理平台等已有系统，本质上都是在做一件事：把 AI 从"能力展示"转化为可复用的工具、规范和工作方式，让它成为研发链路中的一部分，而不是额外负担。
同时，实践也反复验证了一个容易被忽视的事实：研发基础设施本身非常重要。如果底层基建不完善，AI-Native 很难真正跑起来。无论是代码托管平台、内部协作平台还是测试管理平台，这些系统的开放性、稳定性和信息完整度，都会直接影响 AI 能力能否形成闭环。例如，当前 SDD 方案中无法支持 BVT 自动化（基于真实业务环境的功能级接口测试），根本原因并不在 AI，而在于自动化测试平台无法返回测试代码执行时的上下文，导致"分析日志 → 修改代码→ 运行测试"这一链路无法闭合，在短时间无法适配的情况下，只能探索绕过测试平台的新方案。
AI-Native 的探索，必须要能解决真实问题
这半年里，一个非常深刻的体会是：AI-Native 的探索，核心不是追逐新技术，而是解决真实、具体的效能痛点。脱离业务场景的 AI 方案，往往很快就会走到死胡同。
一个比较典型的例子是早期的内部平台知识库管理系统。当时我们投入了将近半个月时间，构建了一个支持多仓库索引、代码托管平台与知识库平台多源文档同步、全文搜索等功能的系统，初衷是解决方案设计和编码过程中的上下文缺失问题。但最终发现，真正的痛点并不是"上下文不够多"，而是"如何管理有限但关键的上下文"。在痛点判断出现偏差的情况下，再复杂的系统也很难产生实际价值，这个方案最终被放弃。
相对而言，API 开放性改造项目则是一个正向案例。这个需求本身并不复杂，只是基于"规范文档 → sub-agent → command"的简单工作流，但由于紧密贴合实际需求和代码结构，最终效果反而非常好：完成了约 3.6 万行代码、210 个 API 的改造，实现了单元测试 100% 覆盖。更重要的是，整个过程被沉淀为一套可复用的标准方案，在研发平台产线内进行分享和推广，实现了有效复制。
AI-Native的本质是"能力沉淀与生态共建"
随着实践的深入，我越来越清晰地认识到：AI-Native 不可能是某一个岗位、某一个部门单独完成的事情，而是一项需要长期投入、跨部门协作的系统性工程。
在实际推进过程中，SPEC 规范由A团队牵头制定，知识库由B团队主导，SDD 方案在C团队中持续完善和推广。不同团队在协作中不断碰撞，也在相互学习借鉴；而使用方提出的反馈，又会反过来推动方案调整和优化，逐步形成"反馈 → 改进 → 推广"的正循环。
这一过程与开源生态非常相似。封闭的 AI-Native 方案很难长期适应快速变化的技术环境和多样化的业务场景，只有保持开放、鼓励共建、持续迭代，方案本身才会具备生命力。
AI-Native 探索中的一些方法论体会
在方法层面，有几点体会比较明确。
首先，不要一开始就追求"大而全"的方案。相比于完美的技术架构，更合理的方式是快速试点、快速验证、允许失败。早期知识库管理系统的失败，与 AI原生开发工具套件这种"贴近业务、分阶段迭代"的阶段性成功，形成了非常鲜明的对比。
其次，不同模型和工具有非常明确的适用边界，合理搭配才能发挥最大价值。在实际使用中，没有任何一个模型或工具可以覆盖所有场景。例如，GLM 的指令遵循性很好，非常适合目标明确、流程清晰的任务；在同样场景下，Claude 或 GPT-Codex 反而不一定占优。而在开发体验上，Cursor、Antigravity 更偏向 IDE 内的闭环效率提升，Claude Code、Codex 则在自由度和异步任务处理上更有优势。
另外，在进行技术预研时，思路往往比反复尝试更重要。如果方向本身不对，让 AI 反复生成代码、不断调试，效率反而很低。比如在办公类文件截断场景的预研中，我一开始执着于二进制流、ZIP 包解析的思路，但 PDF 本质上是一个复杂的对象引用网络，这条路很难走通。转而采用"重建最小可读结构 + 第三方库解析"的方案后，只用了一个小时就完成了编码和验证。
AI-Native对开发者能力结构的影响
AI 的引入正在重塑开发者的能力结构。它降低了部分技术门槛，也模糊了岗位边界（前后端、测试等等），但并没有让研发工作变简单，而是把能力要求从"会不会写代码"，转移到了"能不能做出正确判断"。
一方面，一些能力的重要性正在下降。例如语法细节、API 使用和模板化代码编写，这类重复性、规则明确的工作，已经可以稳定地交给 AI 辅助完成。这些能力不再是区分开发者水平的关键因素。
另一方面，判断力和工程能力的价值被明显放大。能否准确拆解问题、抽象业务模型、做出合理的方案取舍，以及判断 AI 生成内容是否符合业务语义和工程约束，成为 AI-Native 场景下的核心能力。AI 可以给出多种"可行方案"，但不会替开发者承担工程决策的责任。
与此同时，AI-Native 也引入了新的能力要求。开发者需要理解 AI 的能力边界，知道它擅长什么、不擅长什么；需要掌握基本的 agent 使用方式和工具链协作模式，才能将 AI 稳定地纳入研发流程，而不是停留在零散使用。
在实践中我明显感受到，AI 带来的效率提升与个人对业务、工程和工具的熟悉程度高度相关。对这些要素理解越深入，AI 的放大效应越明显。AI 并不是让新手迅速变成专家的捷径，而更像是一个加速器——它让有经验、有判断力的开发者跑得更快。
- Authors
- Name
- IronRookieCoder
近半年AI-Native工作感受与思考
AI-Native：用AI改变开发模式，加速业务发展。
2025 年下半年，我的主要工作围绕 AI-Native 的探索、落地实践和推广展开。借这个机会，对近半年的工作进行了一次系统复盘。这段经历让我对AI Native如何融入研发全流程、真正产生实际价值，形成了一些认知，核心感受从以下维度展开。
AI 融入开发流程，是效能落地的前提
在实践中我逐渐意识到，AI 与业务的结合，并不是简单地把 AI 叠加到原有流程上，也不是推翻既有的研发模式（需求 → 设计 → 开发 → 测试 → 部署）。更现实、也更有效的方式，是在这套已经被验证过的流程中，逐个环节引入 AI 能力，解决具体问题，从而实现整体效率的提升。
这一点在 SDD 流程的搭建过程中体会尤为明显。从内部业务平台内部的孵化试点，到逐步推广成体系化的 SDD 流程；从 SPEC 规范的建设，到 AI原生开发工具套件对SPEC的统一管理，再到通过 MCP 将 AI 能力接入代码托管平台、内部协作平台、测试管理平台等已有系统，本质上都是在做一件事：把 AI 从"能力展示"转化为可复用的工具、规范和工作方式，让它成为研发链路中的一部分，而不是额外负担。
同时，实践也反复验证了一个容易被忽视的事实：研发基础设施本身非常重要。如果底层基建不完善，AI-Native 很难真正跑起来。无论是代码托管平台、内部协作平台还是测试管理平台，这些系统的开放性、稳定性和信息完整度，都会直接影响 AI 能力能否形成闭环。例如，当前 SDD 方案中无法支持 BVT 自动化（基于真实业务环境的功能级接口测试），根本原因并不在 AI，而在于自动化测试平台无法返回测试代码执行时的上下文，导致"分析日志 → 修改代码→ 运行测试"这一链路无法闭合，在短时间无法适配的情况下，只能探索绕过测试平台的新方案。
AI-Native 的探索，必须要能解决真实问题
这半年里，一个非常深刻的体会是：AI-Native 的探索，核心不是追逐新技术，而是解决真实、具体的效能痛点。脱离业务场景的 AI 方案，往往很快就会走到死胡同。
一个比较典型的例子是早期的内部平台知识库管理系统。当时我们投入了将近半个月时间，构建了一个支持多仓库索引、代码托管平台与知识库平台多源文档同步、全文搜索等功能的系统，初衷是解决方案设计和编码过程中的上下文缺失问题。但最终发现，真正的痛点并不是"上下文不够多"，而是"如何管理有限但关键的上下文"。在痛点判断出现偏差的情况下，再复杂的系统也很难产生实际价值，这个方案最终被放弃。
相对而言，API 开放性改造项目则是一个正向案例。这个需求本身并不复杂，只是基于"规范文档 → sub-agent → command"的简单工作流，但由于紧密贴合实际需求和代码结构，最终效果反而非常好：完成了约 3.6 万行代码、210 个 API 的改造，实现了单元测试 100% 覆盖。更重要的是，整个过程被沉淀为一套可复用的标准方案，在研发平台产线内进行分享和推广，实现了有效复制。
AI-Native的本质是"能力沉淀与生态共建"
随着实践的深入，我越来越清晰地认识到：AI-Native 不可能是某一个岗位、某一个部门单独完成的事情，而是一项需要长期投入、跨部门协作的系统性工程。
在实际推进过程中，SPEC 规范由A团队牵头制定，知识库由B团队主导，SDD 方案在C团队中持续完善和推广。不同团队在协作中不断碰撞，也在相互学习借鉴；而使用方提出的反馈，又会反过来推动方案调整和优化，逐步形成"反馈 → 改进 → 推广"的正循环。
这一过程与开源生态非常相似。封闭的 AI-Native 方案很难长期适应快速变化的技术环境和多样化的业务场景，只有保持开放、鼓励共建、持续迭代，方案本身才会具备生命力。
AI-Native 探索中的一些方法论体会
在方法层面，有几点体会比较明确。
首先，不要一开始就追求"大而全"的方案。相比于完美的技术架构，更合理的方式是快速试点、快速验证、允许失败。早期知识库管理系统的失败，与 AI原生开发工具套件这种"贴近业务、分阶段迭代"的阶段性成功，形成了非常鲜明的对比。
其次，不同模型和工具有非常明确的适用边界，合理搭配才能发挥最大价值。在实际使用中，没有任何一个模型或工具可以覆盖所有场景。例如，GLM 的指令遵循性很好，非常适合目标明确、流程清晰的任务；在同样场景下，Claude 或 GPT-Codex 反而不一定占优。而在开发体验上，Cursor、Antigravity 更偏向 IDE 内的闭环效率提升，Claude Code、Codex 则在自由度和异步任务处理上更有优势。
另外，在进行技术预研时，思路往往比反复尝试更重要。如果方向本身不对，让 AI 反复生成代码、不断调试，效率反而很低。比如在办公类文件截断场景的预研中，我一开始执着于二进制流、ZIP 包解析的思路，但 PDF 本质上是一个复杂的对象引用网络，这条路很难走通。转而采用"重建最小可读结构 + 第三方库解析"的方案后，只用了一个小时就完成了编码和验证。
AI-Native对开发者能力结构的影响
AI 的引入正在重塑开发者的能力结构。它降低了部分技术门槛，也模糊了岗位边界（前后端、测试等等），但并没有让研发工作变简单，而是把能力要求从"会不会写代码"，转移到了"能不能做出正确判断"。
一方面，一些能力的重要性正在下降。例如语法细节、API 使用和模板化代码编写，这类重复性、规则明确的工作，已经可以稳定地交给 AI 辅助完成。这些能力不再是区分开发者水平的关键因素。
另一方面，判断力和工程能力的价值被明显放大。能否准确拆解问题、抽象业务模型、做出合理的方案取舍，以及判断 AI 生成内容是否符合业务语义和工程约束，成为 AI-Native 场景下的核心能力。AI 可以给出多种"可行方案"，但不会替开发者承担工程决策的责任。
与此同时，AI-Native 也引入了新的能力要求。开发者需要理解 AI 的能力边界，知道它擅长什么、不擅长什么；需要掌握基本的 agent 使用方式和工具链协作模式，才能将 AI 稳定地纳入研发流程，而不是停留在零散使用。
在实践中我明显感受到，AI 带来的效率提升与个人对业务、工程和工具的熟悉程度高度相关。对这些要素理解越深入，AI 的放大效应越明显。AI 并不是让新手迅速变成专家的捷径，而更像是一个加速器——它让有经验、有判断力的开发者跑得更快。
页面导航
暂无目录