答案不复杂：边界清楚的话，一周可以做出第一版

先说结论：大约一周。

这里的“一周”并不是指做出几张演示页面，也不是把现成接口拼成一个只能跑通 happy path 的样品，而是由一个人借助 AI，从零搭建一套前后端完整、能够在本地运行的 AIOps Agent 工作台。这个项目叫 OncallAgent，它面向真实的值班和故障处理场景，把账号与租户隔离、流式对话、知识库检索、MCP 工具接入、告警诊断、证据留存和报告生成串在了一起。

📷 [图片 token=I64uba5wEo3nlcxo5aBcLoZ4naf（未能下载，见飞书原文）]

OncallAgent 的前端使用 Vue 3、Vite 和 TypeScript，后端基于 FastAPI；聊天 Agent 由 LangChain 组织，诊断流程由 LangGraph 编排；SQLite 保存业务数据，Milvus 负责知识向量，腾讯云官方 CLS MCP Server 提供真实日志能力。它采用本地优先的模块化结构，Docker Compose 只托管必要的基础设施，前端、后端和 MCP Server 都可以在宿主机直接启动。

📷 [图片 token=AX3KbMot0ovz1ixdDLJcoqixn4m（未能下载，见飞书原文）]

听到这里，质疑很自然。认证、聊天、RAG、工具调用和 AIOps 中的任何一项，单独拿出来都不是一天两天能随便做完的功能。更何况系统还要处理 SSE 事件、后台任务、权限过滤、错误契约和可追溯证据。按照常规估算，这通常像是一个小团队需要推进数周的项目。

📷 [图片 token=EU2ZbkHoUofs1LxQB1UcajeQnue（未能下载，见飞书原文）]

所以这篇文章并不准备靠一句“一周做完了”制造惊讶。我更想说明的是：一周究竟完成了什么，哪些工作因为 AI 明显加速，哪些问题仍然必须由人判断，以及为什么同样使用 AI，有的人能交付完整系统，有的人却只得到一堆互相接不上的代码。

效率真正发生变化，是从亲自编码转向持续判断

刚开始使用 AI 时，我也习惯把它当成更强的代码助手：写一个函数、补一组类型、重构重复逻辑，或者生成常见的测试样板。这些用法当然有效，却没有改变项目的推进方式。人依旧需要逐段设计、逐段实现，AI 只是让键盘输入快了一些。

复杂工程的慢，往往不是慢在代码敲得不够快，而是慢在大量相互关联的判断：产品范围应该收在哪里，数据边界如何建立，模块之间通过什么契约协作，异常如何传递，哪些状态必须持久化，哪些基础设施可以暂时不引入。只要这些问题含糊，代码生成得越快，返工通常也来得越快。

📷 [图片 token=PMN1bSA9eoifs9xKpsgcNiqCnAg（未能下载，见飞书原文）]

OncallAgent 让我第一次真正感受到角色变化。我的主要工作不再是把每行代码写出来，而是不断回答几个问题：现在最应该解决什么？这一步的输入和输出是否清楚？AI 交付的结果要怎样验收？如果方案超出了当前目标，应该从哪里裁掉？

这更像一个架构师带着一支执行速度极快的工程团队。AI 可以阅读仓库、实现跨文件改动、补测试、运行检查并根据失败继续修正，但它不会天然知道什么才是这个项目的“合适答案”。产品边界、风险偏好和完成标准，仍然掌握在人手里。

📷 [图片 token=XuJRb0yMkoyIESxgw8xcj884nSd（未能下载，见飞书原文）]

最有价值的产出，不是代码

项目一开始，我曾让 AI 直接为一套 AIOps Agent 系统设计架构。它很快给出了一套看起来相当完整的方案：拆分多个服务，引入注册中心、分布式配置、统一网关、全链路追踪，并为模型、知识索引、MCP 和诊断编排分别建立独立部署单元。

方案并非错误，只是解决了一个并不存在的问题。OncallAgent 的第一阶段服务对象是本地环境中的小团队，目标是在短时间内验证从告警到诊断报告的完整闭环，而不是支撑百万用户的云平台。此时引入复杂的分布式治理，只会让部署、调试和联调成本迅速膨胀。

📷 [图片 token=K95BbigFDobEORxgIVac7ovSnZf（未能下载，见飞书原文）]

那天晚上，我停下了实现工作，先完成三件更重要的事。

**先画清产品边界。**必须做的是认证与用户隔离、持久化流式聊天、知识文档索引与混合检索、用户级 MCP 连接、告警触发诊断、真实工具取证、证据报告和案例沉淀。不做通用的多模型运营后台，不做拖拽式 Agent 编排，也不为了未来可能出现的规模提前拆微服务。

**再确定系统骨架。**前后端在同一仓库中协作，FastAPI 按领域组织后端，Vue 负责工作台交互；SQLite 保存可审计的业务状态，Milvus 只保存带权限字段的知识 chunk 向量；LangGraph 的 Planner、Executor、Replanner 和 Report 节点共同完成诊断；基础设施与应用进程保持清晰边界。

**最后把规则写进仓库。**用户可观察行为先进入 OpenSpec，HTTP 与 SSE 结构由共享契约统一定义，前后端不能各写一套 DTO；所有数据访问必须携带 owner 或 tenant 范围；MCP 只能调用真实发现的工具；没有证据时必须明确说证据不足，不能生成看似合理的根因。

📷 [图片 token=RuRFbhsOVoTjTtxPZP6cjAcGnDg（未能下载，见飞书原文）]

从第二天开始，交给 AI 的任务不再是“帮我把 AIOps 平台做出来”，而变成了可以核验的工作单元。例如：先更新共享契约，再实现用户级 MCP 连接的增删改查和连通性检查，随后接入后端审计与前端状态展示，最后运行对应的类型检查和测试。输入越明确，结果越稳定。

把大需求改写成一串可验收的纵向闭环

与 AI 协作时，拆分粒度决定了返工成本。只按技术层切任务，比如“先写所有数据库表，再写所有接口，最后统一做页面”，很容易在最后联调时集中暴露契约错位。OncallAgent 更适合按用户能感知的闭环推进：一次完成一条从契约、存储、服务、接口到页面和测试的完整链路。

📷 [图片 token=Xl2fbrvFao6pqcxFFOWch8urneb（未能下载，见飞书原文）]

知识库就是一个典型例子。它不是简单的“上传一个文件”，而是一条连续链路：用户创建知识库并上传 Markdown 或 PDF，后台任务解析与切块，索引写入 Milvus，聊天 Agent 以当前用户权限执行向量、BM25 和 rerank 检索，前端再展示来源、阶段排名和分数。删除文档时，元数据与向量也必须在相同 tenant 和知识库范围内清理。

📷 [图片 token=IMJYbtEb5o180Ix84prckwx6nth（未能下载，见飞书原文）]

AIOps 诊断则是另一条闭环：系统读取真实活跃告警，Planner 先检索当前用户可访问的 SOP，Executor 调用实际发现的 MCP 工具获取日志、指标或告警证据，Replanner 根据已有结果决定继续还是调整，Report 最终只依据持久化证据给出结论。成功的诊断还可以沉淀为案例，再参与后续检索。

📷 [图片 token=WnUqbY54WoFb6bxpdICc0zxSnHl（未能下载，见飞书原文）]

当任务被拆到这个程度，AI 才能获得足够上下文，也更容易接受明确的验收标准。每一轮都可以问：共享契约是否同步？跨 tenant 是否真的被拒绝？SSE 是否包含开始、工具调用、完成和结构化错误？工具失败有没有如实进入证据链？页面是否能区分等待、执行、成功与失败？

📷 [图片 token=JmULbSh94oarqqxXNiqcjokjnbb（未能下载，见飞书原文）]

这种做法的重点不是让 AI 多写代码，而是让每次生成都落在一个可以独立验证的范围里。做完一条闭环，系统就多出一项真实能力，而不是多出一批暂时无法证明能协同工作的文件。

和 AI 协作，有两种完全不同的节奏

当方案已经明确时，我使用的是执行式协作。任务中会给出目标、影响范围、必须遵守的规范、相关事实来源和验证命令，AI 负责检查现状、实现最小改动、补齐测试并报告实际结果。人的重点是审查意图是否一致、实现质量是否合格、改动有没有越过边界。

当问题本身还没有想清楚时，直接要求实现往往适得其反。此时更适合使用讨论式协作：先让 AI 阅读规格和代码，列出数据流、约束、遗漏点与可选方案；人根据项目目标做取舍，形成决定之后，再切换到执行阶段。

📷 [图片 token=C3Jnb5UgQoOCsixsIL5cNuPjndc（未能下载，见飞书原文）]

这两种节奏不能混为一谈。探索阶段需要允许多个方案存在，执行阶段则必须有唯一、明确的目标。如果一边让 AI 自由发挥，一边又期待它精准实现一个尚未定义的需求，最后得到的通常是表面完整、内部摇摆的代码。

我在实践中还形成了一个简单的检查顺序。先看它是否理解了真正的需求，再看实现是否通过类型、测试和运行约束，最后检查有没有悄悄扩大范围。这个顺序比逐行阅读所有生成代码更高效，因为许多严重问题在第一层就能被发现：解决错了问题，后面的代码写得再漂亮也没有意义。

📷 [图片 token=OG7rbQiZaofpu8xxyTncp1JGnFe（未能下载，见飞书原文）]

一周交付的背后，是几次关键取舍

OncallAgent 能够快速成形，不是因为把所有想法都实现了，而是因为多次主动拒绝了“看起来更完整”的方案。

架构上，它选择本地优先的模块化实现，没有把应用服务全部塞进 Compose，也没有为了想象中的扩展性拆成微服务。模型接入沿用统一的 OpenAI-compatible provider，不在业务代码里混入多个厂商 SDK。前后端通过共享 API 与 SSE 契约协作，避免在联调阶段依靠口头约定修修补补。

数据上，当前 user ID 就是 tenant 范围。聊天、知识库、向量、MCP 连接、诊断任务、证据、报告和工具审计都必须显式隔离。Milvus 没有授权知识库时直接返回空结果，不能用无范围检索“碰碰运气”。这类约束看起来会增加开发量，却能在早期消灭大量隐蔽返工。

📷 [图片 token=YooLbWtuPoage3xuXZcc5GHAnpe（未能下载，见飞书原文）]

诊断上，系统宁愿说“没有匹配 SOP”或“证据不足”，也不允许编造成功的工具调用、日志内容和根因。真实 MCP 连接失败时，失败本身就是需要保留的事实。对 AIOps 来说，可追溯和不造假比答案显得聪明更重要。

测试上，每次改动先跑最相关的检查，再按影响范围扩大验证。数据库变化验证迁移，API 或 SSE 变化同时检查共享契约、后端和前端，界面变化验证关键状态与布局。AI 能显著降低编写这些测试和修复反馈的成本，但“哪些风险必须被覆盖”仍然需要人来判断。

📷 [图片 token=I4YfbMm5ZorBoHx9Yomc5yo2n6f（未能下载，见飞书原文）]

AI 会放大方向，也会放大含糊

整个过程中，AI 的确承担了大量工作：理解已有仓库、生成跨层实现、补齐类型、编写测试、根据失败日志定位问题、同步文档。若完全手写，同样的工作量很难在一周内完成。

但它也会带来麻烦。约束不足时，它可能给出过度设计；上下文不完整时，它可能在前端和后端各自发明一个相似却不一致的数据结构；跨模块状态复杂时，一次修改也未必能抓住真正原因。AI 的速度不会自动转化为正确性，它只是让正确路线和错误路线都跑得更快。

因此，我更愿意把 AI 看作能力放大器，而不是项目的方向盘。你已经知道目标、边界和判断标准时，它可以把工程推进速度提高一个量级；如果这些前提不存在，它放大的往往是模糊、摇摆和返工。

📷 [图片 token=R4TSbgio5oihepxz916c2ozenth（未能下载，见飞书原文）]

这也解释了为什么“一周”不是一个可以脱离条件复制的数字。技术栈是否熟悉，需求是否克制，仓库规范是否明确，任务能否拆成闭环，验收是否及时，都会改变最终时间。一个人加上 AI，并不自动等于一个成熟团队；只有当这个人真正承担起产品、架构和质量决策，AI 才能成为高效的执行力量。

📷 [图片 token=HrLRbbVWfoYj1mxmlJrccogenxd（未能下载，见飞书原文）]

真正值得复用的，不是某个工具版本

工具更新很快，今天常用的命令、交互方式和上下文能力，几个月后都可能变化。如果学习重点只停留在某个功能按钮或提示词模板上，经验很容易随着版本迭代失效。

更持久的能力是：面对复杂需求时，能否先识别系统边界；能否把模糊目标转成明确规范；能否把大工程拆成可验证的纵向任务链；能否从意图、质量和边界三个层面审查 AI 输出；能否在证据不足时拒绝一个看似漂亮的答案。

📷 [图片 token=H8G1bfGZno3xVUxb0XrcG2P7nGg（未能下载，见飞书原文）]

所以回到标题：一个人用 AI 写一个 Agent 项目需要多久？对于 OncallAgent 这样的首个可运行版本，一周左右是可以实现的。但真正让这个数字成立的，不是 AI 替人完成了思考，而是人先完成关键判断，再让 AI 把判断快速变成代码、测试和可运行的系统。

当这种协作方式建立起来，你得到的不只是一个项目，也不是对某款工具的依赖，而是一套可以迁移到下一套技术栈、下一个 Agent 和下一代 AI 编程工具上的工程方法。

📷 [图片 token=YrB5bwkhcoAcMGxykZZcR8XSnfO（未能下载，见飞书原文）]