AI 编程、代码生成、测试生成、文档生成和 AI Agent 快速进入软件研发之后，一个很自然的问题是：既然开发方式越来越快、越来越自动化，传统瀑布型项目是不是已经不适合了？如果只看“代码怎么写”，这个判断似乎有一定道理。AI 可以把过去需要几天完成的原型、接口草稿、测试用例甚至部分功能代码压缩到几个小时，传统按照“需求完成后再设计、设计完成后再开发”的严格串行方式，确实容易显得笨重。但软件项目并

上一篇介绍了 Function Calling：让大模型能够根据用户目标选择工具、生成参数，并调用数据库、业务 API 或其他程序能力。但 Agent 真正接入业务系统后，还存在另一个同样重要的问题：模型产生的结果，怎样可靠地交给程序处理？例如用户告诉 Agent：请创建一个任务：8 月 14 日前完成华东区客户回访方案，优先级高，负责人张晨，预算不超过 5000 元，并拆成整理客户名单、执行回访

引言：当 AI 不再只是坐在工具栏里在上一篇文章中，我们讨论了 AI 正在改变需求、设计、开发、测试和项目协同，而不只是提高代码生成速度。当 AI 的能力继续向任务规划、工具调用、代码执行和结果验证延伸，一个更深层的变化开始出现：AI 不再只是项目成员使用的工具，而是逐渐成为项目流程中的参与者。早期的 AI 更像一个随叫随到的助手，能够回答问题、生成内容，却不会持续跟踪任务；今天的 AI Agen

在前面的文章中，我们已经介绍了大模型应用开发所需的基础知识，以及 Prompt Engineering 和 Context Engineering 如何帮助模型理解任务、组织信息并形成判断。然而，理解问题并不等于完成任务。模型可以识别用户想查询天气、分析销售数据或创建审批任务，但如果不能连接天气服务、业务数据库和审批系统，它最终仍然只能生成文字。Function Calling 解决的正是从“语言

在企业办公、合同管理、知识库、档案管理和云文档等系统中，文件既是业务信息的主要载体，也是 Agent 执行真实任务时必须面对的对象。用户可以直接向 Agent 提出：打开这份合同，定位付款条款；把一批 Office 文件统一转换成 PDF；合并这些 PDF，并添加“内部资料”水印；提取文档正文，生成摘要并写入知识库；清除 Word 中的批注和修订，生成正式版本。大模型能够理解这些自然语言指令，但并

 过去一轮 AI 办公主要解决的是内容生成问题：用户在聊天框中提出要求，AI 返回一段文字、一张表格或一份演示文稿，再由用户复制、下载和修改。腾讯 WorkBuddy 展示的则是另一种产品形态——以 Agent 为统一入口，把任务、项目、知识、文件、连接器和在线编辑能力组织到同一个工作环境中，使 AI 不只是回答问题，而是参与完整的办公流程。对于希望建设企业级 AI Office 的团队而言，Wo

在本系列的开篇中，我们提出了一个基本判断：AI 对软件项目的影响，正在从个人效率工具扩展到项目运行方式。项目经理面对的管理对象，也开始从人员、任务和资源，延伸到模型、AI 工具、Agent、知识库、自动化流程以及由它们生成的各种成果。进入第一部分“趋势与基础概念”，首先需要进一步回答一个问题：AI 究竟改变了软件项目的哪些地方？提到 AI 与软件研发，很多人首先想到的仍然是代码补全、代码生成和 V

过去几年，AI 给软件研发带来的变化，最先体现在代码生成上。从代码补全、文档生成和数据分析，到需求整理、方案设计、测试用例生成、缺陷定位，再到能够自主拆解任务、调用工具并持续执行的 AI Agent，AI 正在进入软件项目的各个环节。它带来的影响，也开始从“提升个人效率”转向“改变团队协作和项目运行方式”。当项目团队中出现 AI 编程助手、需求 Agent、测试 Agent、文档 Agent，甚至

​ 在上一篇《开发 Agent 前需要掌握哪些大模型基础》中，我们介绍了 Token、上下文窗口、消息角色、Structured Output、Function Calling、Embedding 与 Rerank 等基础能力。这些能力解决了“大模型如何接入应用”的问题，但当应用从一次问答升级为需要多轮推理、检索资料和调用工具的 Agent 时，开发者很快会遇到另一个问题：模型能力并不差，Prom