过去一段时间，我在一个已有一定规模的前端 / 桌面端项目里持续尝试 Agentic Coding。这里的重点不是"某个模型到底有多聪明"，而是：AI 怎样真正进入日常研发流程，并逐步变成团队可以复用的工程能力。
很多人第一次使用 AI 写代码时，习惯把它当成一个更强的问答工具：贴一段需求，让它生成代码，再人工复制进去。但在真实项目里，这种方式很容易失控。项目越成熟，目录结构、接口封装、页面模式、样式规范、测试方式就越重要。AI 如果不了解这些上下文，就会把自己的假设写进代码里，短期看似很快，长期反而增加返工。
所以我现在更关注的是流程，而不是单次生成效果。
先计划，再实现
面对一个需求，我不会让 AI 一上来直接写代码，而是先让 Codex 进入 Plan 模式。这个阶段会让 AI 阅读项目规则、相关代码、已有模式和边界条件，然后拆出目标、影响文件、潜在风险和验证方式。
计划出来以后，也不会马上进入实现。我会先人工 review 方案，重点看几个问题：
- 它有没有误解业务目标？
- 它有没有扩大修改范围？
- 它是否符合项目已有接口层、组件层和样式约定？
- 它有没有写清楚验证方式？
如果计划有问题，就继续要求 Codex 更新计划，直到每个关键流程都确认无误，再进入开发。这个步骤看起来比"直接开写"慢一点，但实际能显著减少误改、返工和上下文偏移。
我现在更愿意把 AI 当成研发流程里的一个节点：需求澄清、方案拆解、实现、自检、验证、总结，都可以让它参与，但每一步都要有边界。
让 AI 在真实仓库里工作
Agentic Coding 的收益，在真实仓库里会更明显。因为真实仓库里有大量可复用信息：目录结构、组件封装、请求层、样式变量、业务约束、历史实现方式。这些信息如果能被 AI 读取和遵守，输出质量会比单纯靠 prompt 稳定得多。
我比较看重 AI 编程助手的几个能力：
- 能围绕本地仓库持续工作，而不是只生成代码片段。
- 能读文件、查上下文、跑命令、做验证。
- 能把调研、计划、实现、review 和总结串成一次完整会话。
- 能通过工具调用接入浏览器、设计稿、文档和任务流程。
它的价值不只是"生成代码"，而是把一段原本分散的研发动作组织起来。
我目前主要使用 Codex 做这类工作。原因不只是模型能力，也包括客户端能力、工具调用、本地仓库协作、验证链路和成本可预期性。Claude Code 也有很强的能力，但不同工具在用量限制、账号稳定性、插件生态和团队预算上各有取舍。真正重要的不是押注某个名字，而是选择能稳定接入团队流程的工具。
计划能力比 prompt 技巧更重要
复杂需求里，最容易出问题的不是代码语法，而是方向。需求不清、设计不清、规则不清时，AI 很容易把"自己的假设"直接写成实现。
因此，计划能力比 prompt 技巧更重要。一个好的计划至少应该回答：
- 这次到底要解决什么问题？
- 哪些文件或模块会受影响？
- 哪些地方不能动？
- 怎么确认改完是对的？
- 如果 UI 或接口有不确定性，应该先问什么？
当计划足够清晰以后，AI 更像一个高效执行器；如果计划不清晰，它就会变成一个高效制造偏差的工具。
用隔离工作区做并行开发
另一个很有价值的实践是使用隔离工作区。对于可以拆开的任务，可以让不同任务在不同工作区里并行推进。这样做有几个好处：
- 每个上下文更小，AI 更容易聚焦。
- 变更之间相互隔离，合并时更清晰。
- 一个任务失败，不会污染主工作区。
- 多个方向可以同时验证，节省等待时间。
并行不是为了看起来更快，而是为了让变更边界更清楚。
设计稿要变得 AI 友好
UI 类需求是 Agentic Coding 很容易产生收益的场景。相比纯文字描述，结构化设计上下文能让 AI 更快理解布局、层级、状态和交互关系。
但这里有一个前提：设计稿本身也要对 AI 友好。比如：
- 使用组件化结构，而不是一堆散乱图层。
- 图层和组件命名有语义。
- 使用自动布局、变量和设计 token。
- 尽量保留文本、颜色、间距、状态等可识别信息。
- 对复杂交互补充说明。
如果只给 AI 一张截图，它只能猜。如果能给它结构化设计信息，它就能更准确地映射到代码实现。
在工具支持上，我更推荐优先使用 Figma 这类成熟设计工具链，并通过 Figma MCP 让 AI 读取具体页面、模块或组件的上下文，而不是只靠图片识别。Codex 官方插件市场已经支持 Figma，Claude Code 对 Figma 的支持也很完整；相比之下，蓝湖这类工具目前还缺少成熟的官方 AI 编程插件路径，落地成本会明显更高。
把个人经验沉淀成团队资产
很多团队一开始会沉迷于 prompt，但 prompt 往往是一次性的。真正更有价值的是把经验沉淀成团队可复用的规则和技能。
比如在项目里沉淀几类指导：
- 请求层应该怎么封装。
- 表单、弹窗、列表联动应该遵守什么模式。
- 样式应该放在哪里，哪些变量可以复用。
- 完成任务前必须跑哪些检查。
- 什么情况下必须先计划，什么情况下可以直接修改。
这些规则一旦固定下来，AI 就不只是听某个人临时指挥，而是能沿着团队已有工程经验工作。团队复用同一套规则，输出也会更稳定。
除了项目自定义规则，我也会借鉴一些开源 skills，比如 brainstorming、writing-plans、verification-before-completion 这类通用工作流。Claude Code 的 skill 也不一定只能在 Claude Code 里用，很多时候可以让 Codex 帮忙改写成更适合 Codex 的版本：替换工具调用、调整路径约定、补上本仓库的验证命令和权限边界。
AI 不只写代码
在实际工作里，AI 的价值不止于写代码。它还可以参与很多上游和下游工作：
- 帮产品经理做头脑风暴、方案比较和需求收敛。
- 帮测试同学补充测试点、边界场景和回归清单。
- 帮研发做资料整理、技术调研和文档草稿。
- 帮团队把一次性的经验整理成长期可复用的文档。
调研类任务尤其适合结合浏览器能力。Codex 官方联网搜索适合快速查资料和拿引用，但更复杂的产品调研往往需要真实浏览器环境：登录态页面、动态渲染、点击滚动、截图、媒体提取、多页面并行访问等。这里我会搭配 web-access 这类浏览器调研插件，让 AI 更接近真实用户访问网页的方式。
语音输入也是一个容易被低估的效率点。很多时候，我们不是想不清楚，而是懒得打字。我现在会用 Typeless 把口头想法快速整理成更清晰的文字，再交给 AI 继续处理。它不只是语音转文字，更像是把零散表达整理成可执行输入。
边界仍然很重要
当然，这些实践还没有覆盖所有场景。比如测试驱动开发、Web 端自动化测试、桌面客户端自动化测试等流程，还需要继续验证，不能过早包装成成熟经验。
我现在比较确定的收益主要来自这些方向：
- 计划先行。
- 仓库上下文读取。
- 设计稿到 UI 的结构化落地。
- 团队规则和技能沉淀。
- 隔离工作区并行开发。
- 调研和文档辅助。
而需要继续探索的是更完整的自动化验证链路，以及如何在团队层面稳定推广。
结语
Agentic Coding 的核心不是"谁的 prompt 更厉害"，也不是"AI 能不能一次写出完美代码"。真正重要的是：我们能不能把 AI 接入已有工程体系，让它理解上下文、遵守规则、执行计划、完成验证，并把个人经验沉淀成团队资产。
从这个角度看，AI 编程不只是效率工具，而是一种新的研发协作方式。