过去的软件项目启动，重点通常放在业务价值、技术可行性、预算、周期、资源和风险上。只要目标基本清楚、技术路线可行、人员能够到位，项目就可以进入后续需求和设计阶段。
AI 进入软件研发以后，这套判断标准仍然有效，但已经不够完整。
因为同一个项目中，AI 可能只是帮助项目经理整理材料，也可能参与需求分析、代码生成、测试、文档编写，甚至以 Agent 的方式直接调用工具、修改代码或执行任务。AI 参与程度不同，对数据、知识、工具、安全和责任机制的要求也完全不同。
所以，AI 时代的软件项目启动，除了回答传统的“这个项目能不能做”，还需要多回答一个问题：
这个项目中的哪些工作适合交给 AI，以及我们是否具备让 AI 安全、稳定、可控地参与这些工作的条件。
这就是项目启动阶段新增的 AI 可行性分析。
一、AI 可行性分析，不是再增加一份技术评估
传统立项通常会围绕几个基本问题展开：
业务上值不值得做 ↓ 技术上能不能实现 ↓ 预算和周期是否可接受 ↓ 资源是否能够支撑 ↓ 主要风险是否可控
AI 可行性分析并不是在这些内容之外单独再增加一个“模型选型”环节，而是把 AI 作为新的生产能力纳入整个项目判断。一个更完整的启动评估可以扩展为：
业务可行性 + 技术可行性 + 交付可行性 + AI 适用性 + 数据与知识条件 + 工具与 Agent 条件 + 安全与合规要求 + 审核与责任机制
也就是说，项目启动阶段既要确认系统本身是否能够建设，也要判断 AI 是否真的值得进入这个项目，以及应该进入到什么程度。这两件事不能混为一谈。一个项目完全可以在技术上可行，但并不适合大量使用 AI；反过来，一个项目也可能有很多适合 AI 的任务，但现有数据、安全条件和工程基础还不足以支撑 Agent 自动执行。
二、第一步不是选模型，而是识别“哪些工作值得 AI 参与”
很多团队讨论 AI 项目时，第一反应往往是：
用哪个大模型？
用 ChatGPT、Claude，还是国产模型？
是不是要搭 Agent？
但对软件项目管理来说，这个顺序其实反了。项目启动阶段更应该先回答：
项目中的哪些工作值得使用 AI？
因为不同任务的 AI 适配度差异很大。例如：
| 项目工作 | AI 适配度 | 更合理的参与方式 |
| 会议纪要、材料整理 | 高 | AI 直接辅助生成 |
| 需求初稿、需求归纳 | 高 | AI 生成 + 人工确认 |
| 原型说明、接口草稿 | 中高 | AI 辅助 |
| CRUD、脚本、模板代码 | 高 | AI 生成 + Review |
| 测试用例初稿 | 中高 | AI 生成 + 测试人员完善 |
| 架构设计 | 中 | AI 推演，人做决策 |
| 复杂业务规则 | 中低 | AI 辅助分析 |
| 遗留系统改造 | 中低 | AI 辅助理解和局部修改 |
| 安全关键代码 | 低到中 | 强审核、有限参与 |
| 最终验收决策 | 低 | AI 辅助检查，人负责确认 |
判断的关键不只是“AI 能不能做”，而是：
AI 做这件事以后，是否真的比人工更高效，而且生成结果是否容易验证。
例如，生成一份测试用例初稿很快，而且测试人员可以通过需求和实际执行验证结果，这类任务通常适合 AI。
但如果让 AI 独立完成一个复杂行业系统的核心业务建模，虽然它也能给出方案，验证成本却可能非常高，甚至需要资深业务人员重新分析一遍，那么所谓的“提效”就未必成立。因此，AI 适用性判断可以简化成三个问题：
是否容易生成？ + 是否容易验证？ + 出错后影响是否可控？
只有三者都比较合适，才适合提高 AI 的参与程度。
AI 任务适配判断模型
编辑
这张图可以用于说明一个核心原则：AI 参与度不应只根据模型能力决定，还应同时考虑验证成本和错误风险。
三、第二步要评估的，是项目有没有足够的“上下文”
AI 能力再强，如果拿不到正确的项目上下文，也很难产生稳定结果。例如让 Agent 修改一个已有系统中的权限模块，它至少可能需要知道：
- 当前需求是什么；
- 已有权限模型如何设计；
- 数据库结构是什么；
- 当前代码有哪些约束；
- 接口规范是什么；
- 项目有哪些编码标准；
- 历史上为什么做过某些技术取舍。
如果这些信息散落在聊天记录、个人电脑、旧文档和不同代码分支里，那么 Agent 很可能只能依靠局部信息做判断。所以 AI 可行性分析不能只看：
有没有数据？
还要看：
有没有 AI 能够真正使用的上下文。
可以把项目的 AI 上下文条件分成几类：
需求上下文 ├─ 需求规格 ├─ 用户故事 └─ 验收标准 技术上下文 ├─ 架构设计 ├─ 数据模型 ├─ API 定义 └─ 编码规范 工程上下文 ├─ 代码仓库 ├─ 测试环境 ├─ CI/CD └─ Issue / 缺陷记录 业务上下文 ├─ 制度 ├─ 业务规则 ├─ 历史案例 └─ 企业知识库
如果项目资料本身就不完整、不一致，AI 往往会放大这种问题。这意味着，AI 时代的软件项目启动还承担一个新的任务：
判断项目知识是否已经具备结构化、可检索、可复用的基础。
这也是为什么项目知识库在 AI 时代不再只是文档归档工具，而越来越接近 Agent 的基础设施。
四、有数据，不等于数据可以直接交给 AI
数据条件是 AI 可行性分析中最容易被低估的一部分。软件项目里可能存在大量：客户资料、业务数据、源代码、数据库结构、接口信息、合同、需求文档、日志、账号信息和生产环境数据。
这些内容并不是只要能提高 AI 效果，就可以直接提交给模型。项目启动阶段需要先对数据进行分类。例如：
| 数据类型 | AI 使用建议 |
| 公开技术资料 | 通常可以使用 |
| 通用需求模板 | 可以使用 |
| 企业内部一般资料 | 根据内部制度使用 |
| 项目源代码 | 需要明确模型和工具边界 |
| 客户业务数据 | 需要严格控制 |
| 个人信息 | 需要脱敏和授权 |
| 密钥、Token、密码 | 不允许进入模型上下文 |
| 涉密或强合规数据 | 通常应限制或禁止外部 AI |
所以项目启动阶段应该形成一个很明确的关系：
项目数据 ↓ 数据分类 ↓ AI 使用权限 ↓ 允许进入哪些模型 / Agent ↓ 是否需要脱敏 ↓ 是否需要私有化部署
AI 工具是否可用，最终不仅是一个产品选型问题，更是一个项目数据治理问题。
五、AI 工具选型，要从“个人偏好”升级为项目决策
在 AI 使用初期，经常出现一种情况：
开发人员自己选择编程助手；
测试人员自己选择大模型；
项目经理使用另一套 AI；
不同成员分别使用不同账号和服务。
在个人效率阶段，这种方式问题并不明显。
但当 AI 产生的内容开始进入正式项目，甚至 Agent 可以访问代码、数据库、文件系统和内部接口以后，工具就不能继续完全由个人决定。
项目启动阶段至少应该明确四类工具。
第一类：通用大模型
主要用于需求分析、总结、方案讨论、文档生成和知识问答。
重点关注：
模型能力、数据策略、上下文长度、成本和服务稳定性。
第二类：AI 编程工具
用于代码生成、修改、解释、Review 和测试。
除了模型能力，更需要关注：
代码是否上传云端；
能否限制仓库访问范围；
是否支持企业账号；
生成结果如何进入正常代码评审流程。
第三类：企业知识与 RAG
用于让模型获得企业制度、项目文档、历史方案和业务知识。
重点已经不只是模型，而是：
文档解析 + 知识切分 + 权限控制 + 检索 + Rerank + 引用 + 知识更新
第四类：AI Agent 平台
Agent 的风险明显高于普通聊天工具，因为它可能拥有真实执行权限。例如：
读取代码 修改文件 调用 API 查询数据库 创建任务 操作项目系统 执行脚本
因此，Agent 选型必须同时考虑权限控制、工具调用、审计、人工确认、失败重试和回退能力。
六、Agent 是否适合进入项目，要看“工程基础”而不是只看模型能力
一个经常出现的误区是：
模型已经很强了，所以可以让 Agent 自动开发。
真正决定 Agent 能否稳定工作的，很多时候并不是模型，而是项目本身的工程化程度。例如，让 Dev Agent 自动修改代码，需要依赖：
清晰需求 ↓ 代码仓库规范 ↓ 可重复构建环境 ↓ 自动化测试 ↓ 静态检查 ↓ 代码 Review ↓ CI/CD
如果项目连自动化测试都很少，Agent 修改代码以后就很难快速判断是否正确。同样，如果接口规范、代码规范和环境配置高度依赖开发人员个人经验，Agent 的自动化程度也很难提高。所以，在立项时评估 Agent 可行性，可以使用这样一个简单判断：
| 工程条件 | Agent 参与基础 |
| 需求明确 | 能判断做什么 |
| 代码规范 | 能稳定修改 |
| 构建自动化 | 能验证是否可构建 |
| 自动化测试 | 能验证功能 |
| CI/CD | 能形成执行闭环 |
| 权限体系 | 能限制 Agent 行为 |
| 日志和监控 | 能发现异常 |
| 回滚能力 | Agent 出错后能够恢复 |
这也解释了为什么同一个 Agent，在成熟工程团队中可能表现很好，放到另一个历史系统里却很难稳定工作。
Agent 的上限由模型能力决定，但 Agent 能否真正进入生产项目，往往由工程基础决定。
AI / Agent 可行性的四层基础
编辑
这张图可以作为本文的核心图。它说明 AI 可行性不是一个单点判断，而是由任务、上下文、工程和治理共同决定。
七、AI 加入以后，项目成本评估也要重新计算
AI 经常被理解成“降低项目成本”。但在正式软件项目中，成本变化没有这么简单。AI 的确可能降低部分工作量，例如：
文档整理时间减少；
代码模板生成更快；
测试用例准备效率提高；
问题分析速度提升。
但同时也会出现新的成本：
模型调用成本 + AI 工具许可证 + Agent 平台成本 + 知识库建设成本 + 私有化部署成本 + AI 输出审核成本 + 测试验证成本 + 错误返工成本
因此，项目启动阶段不应该简单地按照：
“用了 AI，所以开发人数减少 30%。”
去调整项目预算。更合理的方式是重新计算整个交付链路。例如过去一个任务可能是：
人工开发 5 天
AI 加入以后可能变成：
AI 生成 1 天 + 人工 Review 1 天 + 测试验证 1 天 + 问题修改 1 天
总周期确实下降了，但并不是直接变成“1 天”。所以，AI 时代项目成本评估的关键是：
不要只计算生成成本，还要计算验证、治理和返工成本。
八、AI 风险需要从项目启动阶段就进入风险登记册
传统项目风险通常包括：需求变化、人员不足、技术难题、进度延期、第三方接口和客户配合等。AI 参与以后，还会增加一批新的风险。例如：
| 风险 | 典型表现 |
| AI 幻觉 | 生成错误需求、代码或结论 |
| 数据泄露 | 项目资料进入未经批准的模型 |
| 代码安全 | 生成存在漏洞的代码 |
| 工具依赖 | AI 服务中断或能力变化 |
| 成本失控 | 模型调用量持续增加 |
| 上下文错误 | Agent 使用了旧需求或错误资料 |
| 自动化失控 | Agent 执行了超出授权的操作 |
| 责任模糊 | AI 生成物未经审核进入交付 |
| 团队依赖 | 成员逐渐失去基础判断能力 |
这些风险不能等到项目进行了一半再处理。因为一旦项目已经大量依赖某个模型、工具或者 Agent，再改变方案的成本通常会更高。因此，AI 项目风险应该和传统项目风险一起，在启动阶段完成第一次识别。
九、AI 参与项目，还需要提前设计责任边界
AI 时代的项目启动最终必须回答一个非常现实的问题：
AI 生成结果出了问题，谁负责？
答案不能是“AI”。所以，项目启动阶段就应该形成基本的责任原则。例如：
AI 生成需求 → BA / 产品负责人确认 AI 生成架构方案 → 架构师确认 AI 生成代码 → 开发负责人 Review AI 生成测试 → 测试负责人确认 PM Agent 生成风险结论 → 项目经理判断和处理
这意味着项目中的 Agent 应该是：
有任务、有权限、有审核、有验收、有责任人的受控协作者。
而不是一个独立承担项目责任的“数字员工”。
十、项目启动阶段，可以增加一张“AI 使用边界表”
为了避免项目开始以后每个人按照自己的理解使用 AI，可以在启动阶段形成一份简单的 AI 使用边界。例如：
| 项目事项 | 约定 |
| 允许使用的 AI 工具 | 企业批准工具 |
| 禁止使用的数据 | 密钥、生产数据、敏感客户资料 |
| AI 可参与任务 | 需求整理、代码辅助、测试、文档 |
| Agent 可访问系统 | 指定代码库、测试环境、项目知识库 |
| 是否允许自动修改 | 默认需要人工确认 |
| AI 结果审核 | 对应专业负责人 |
| AI 结果进入基线 | 必须通过项目正常评审 |
| 异常处理 | 停止 Agent → 人工接管 → 回退 |
内容不需要非常复杂。关键是让所有团队成员在项目开始时形成统一认知：
AI 在这个项目里能做什么、不能做什么，以及谁对最终结果负责。
十一、AI 时代的软件项目启动，可以形成新的评估闭环
把前面的内容放到一起，AI 时代的软件项目启动可以形成一套更加完整的流程：
编辑
最终输出的不应该只是“这个项目准备使用某个大模型”。而应该至少明确：
哪些任务使用 AI + 使用什么工具和模型 + AI 可以访问哪些数据 + Agent 有什么权限 + 哪些工作必须人工审核 + 采用什么质量验证机制 + 存在哪些 AI 风险 + 最终责任如何划分
当这些问题基本明确以后，AI 才真正从“团队成员自己使用的效率工具”，变成项目计划中的正式能力。
十二、结语：不要等项目开始以后，再决定怎么使用 AI
AI 很容易进入软件项目。开发人员打开一个 AI 编程工具，项目经理开始用模型整理文档，测试人员生成几批测试用例，几乎不需要正式流程。难的是，当这些 AI 产出真正开始影响项目范围、代码质量、数据安全和最终交付以后，项目还能不能保持可控。所以，AI 时代的软件项目启动，需要比过去多做一步：
不仅评估项目是否可行，还要评估 AI 如何参与这个项目才可行。
真正成熟的做法不是项目已经开始以后，再由每个成员决定怎么使用 AI，而是在立项和启动阶段就把 AI 当成一种新的项目能力、项目资源和项目风险统一规划。
传统项目启动解决的是：
这个项目应该怎么做。
AI 时代还需要继续回答：
哪些工作应该由人做，哪些可以交给 AI；AI 能看到什么、能操作什么；生成结果如何验证，以及最终谁负责。
当这些边界清楚以后，AI 才能真正成为项目效率的放大器，而不是新的不确定性来源。
上一篇回顾：
https://developer.aliyun.com/article/1754954?spm=a2c6h.13148508.setting.15.5fbe4f0e1ZHtMQ
下一篇将进一步讨论：
从需求分析、原型设计、文档整理、代码生成、测试、数据分析等实际工作出发，建立一套 AI 任务适配与参与度判断方法，帮助项目在启动阶段就确定：
哪些任务值得 AI 参与，以及 AI 应该参与到什么程度。
— 持续更新 · 欢迎关注 —
