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