AI时代软件开发，OPC探索之路

本文中的 OPC，指一个人主导、借助 Agent 协作推进软件开发的工作方式。这个博客尚未验证一人公司的商业模式；文章记录一个个人项目如何从需求、设计走到代码、联调与部署，以及这套协作方式怎样在实际推进中逐步形成。

本文以一个需求的推进过程为主线：怎样把想法变成共同目标，怎样组织团队与子 Agent，怎样处理反馈并核对交付。方法来自博客项目的实际探索，具体功能片段集中放在文末。

1. 先明确：一个人负责什么，Agent 负责什么

项目负责人确定目标、优先级和重大取舍，决定方案是否可接受、结果是否仍需验证。项目工作流以产品、UI/UX、前端和后端为核心角色，主代理拆分任务、处理依赖和整合结果；实际推进还使用独立的运维与文档会话，产品会话负责统筹文章迭代。角色代表负责的工作，团队会话则保存持续推进的上下文，两者不必一一对应。

项目负责人提出目标并判断方案，产品把目标整理为范围和验收条件，设计与技术团队将其转成可实施的方案。推进中发现遗漏或重大取舍时，再回到相应责任人；Agent 不自行把建议升级为已确认需求。

Agent 报告“完成”不能直接等同于项目完成。设计稿按页面实际支持的设备与窗口检查，前台包括移动阅读，后台则检查桌面窗口；接口核对契约和真实请求；生产更新核对服务器版本记录、健康检查与实际访问结果。最终的取舍和验收责任由项目负责人承担。

2. 工作流是怎样搭起来的

这套工作流在实践中逐步固定了任务入口、交接格式、文件所有权和验收关口。

仓库根目录的 AGENTS.md 统一职责与协作边界，.agents/skills/ 保存按任务选用的方法。例如，团队工作流规定交接与整合，前端 Skill 约束样式、滚动区和组件定制。安装 Skill 不等于已完成相应能力，当前事实仍要核对文档与代码。

续接先核对当前任务和版本，再复用仍有效的结果；历史讨论不自动成为现行需求。

仓库如何支撑分工

仓库目录也按这套分工组织。下面只列主要入口：

blog/
├─ next/                    Next.js 页面与后台
├─ auth-service/            Go 认证服务
├─ blog-service/            Go 文章服务
├─ nginx/                   对外网关
├─ infrastructure/
│  ├─ deployment/           Compose、发布、状态与回滚
│  ├─ webhook/              GitHub 事件接收
│  ├─ mysql/                数据库备份与恢复
│  └─ migrator/             数据库结构迁移
├─ contracts/               前后端共享语义与发布协议
├─ docs/                    产品、设计、工程、决策与交付状态
├─ .agents/skills/          按任务选用的专业方法
├─ .github/workflows/       CI 工作流
├─ AGENTS.md                项目级协作规则
└─ Taskfile.yml             本地、测试与发布命令入口

目录与团队责任的对应关系如下：

目录所有权属于协作约定，未由操作系统强制隔离。动手前检查分支与未提交改动，明确可写文件，保留其他团队工作；跨域任务交给对应会话。

任务如何流转

任务从项目负责人提出需求或变更开始。 下图是跨团队交付关系；小修改沿对应环节处理，无须重走全流程。

flowchart TB
    START(["需求入口：项目负责人提出新需求或变更"]) --> M["主代理：核对现状、授权与文件所有权"]
    M --> P["产品 Agent：需求范围与验收条件"]
    P --> D["设计 Agent：交互、视觉与页面状态"]
    P --> T["前后端 Agent：技术方案与共享契约"]
    D --> T
    T --> F["前端 Agent：next/ 实现与验证"]
    T --> B["后端 Agent：Go 服务、数据与迁移"]
    D -. 设计交接 .-> F
    F --> I["前后端 Agent：真实接口联调"]
    B --> I
    I --> Q["产品 Agent：功能验收"]
    I --> X["设计 Agent：视觉与交互走查"]
    Q --> V{"主代理：核对证据并整合"}
    X --> V
    V -->|需要修正| FIX["返工：主代理交回对应责任 Agent"]
    FIX -. 需求问题 .-> P
    FIX -. 设计问题 .-> D
    FIX -. 前端问题 .-> F
    FIX -. 后端问题 .-> B
    V -->|达到验收条件| A["项目负责人：接受结果及决定是否发布"]
    A -->|本阶段交付| END["记录结果、证据与下一步"]
    A -->|授权发布| R["运维 Agent：部署与备份；后端提供迁移规则"]
    R --> S["运维、产品与前端：健康和用户流程检查；主代理汇总"]
    S --> END
    classDef entry fill:#d7eff5,stroke:#167888,stroke-width:3px,color:#123c46
    class START entry

契约明确后，前后端并行开发，再联调汇合。返工回到问题所属环节，整合核验不代替项目负责人的最终决定。

团队内部：主 Agent 与子 Agent 怎样配合

项目统筹协调团队之间的依赖；团队主 Agent 负责本域交付，子 Agent 承接有明确边界的临时任务。团队会话保留持续上下文，子 Agent 随任务安排，并非固定岗位。小修改可由主 Agent 直接完成，独立实施或审查才拆分。

flowchart TB
    C["项目统筹：范围、跨团队依赖与交付状态"] --> M["团队主 Agent：核对现状，划分任务与文件所有权"]
    M --> W["实施任务：主 Agent 直接完成\n或委派子 Agent 独占指定文件"]
    M --> Q["审查子 Agent：只读核对\n报告问题、证据与未验证项"]
    W --> E["团队主 Agent：修正问题，验证组合结果"]
    Q --> E
    E --> R["交付产物、验证范围与下一步"]
    R --> C

图示表示职责关系；审查要读取实际产物，依赖前序结果的任务顺序执行。可独立的任务才并行，共享文件和 Figma 写入仍串行；作者的自检不能充当独立审查。

这是本轮整理的实际记录，不能推及每次功能开发。前端本轮通过类型检查与构建，但未验证浏览器交互；运维完成配置检查，未执行真实部署。文档团队则负责本篇文章的整理，未列入该轮五团队审查。

跨会话交接：交什么，怎样收回结果

sequenceDiagram
    participant A as 发起团队
    participant B as 接收团队主 Agent
    participant S as 子 Agent（按需）
    A->>B: 原始要求、已确认范围、精准路径与已做工作
    A->>B: 文件所有权、依赖、验收与停止条件
    opt 任务值得拆分
        B->>S: 有边界的实施或只读审查
        S-->>B: 产物、证据、问题与未验证项
    end
    B->>B: 检查实际产物与组合结果
    B-->>A: 完成范围、验证环境与版本、待办
    A->>A: 更新本域事实和交付状态

交接消息送达只代表任务已转交。接收团队核对实际产物后回报，发起团队再更新状态；产物、实际验证、用户接受与生产发布各自需要证据和授权。

3. 一个需求怎样在协作中逐步成形

项目中的需求往往先是一句话，推进后才暴露权限、异常状态、环境和交付范围。这一章从实际过程抽取共同路径，不限定某项功能，也不代表每次都要经过全部角色。

3.1 从一句话到可验证的范围

产品先整理谁在什么场景完成什么、哪些内容本次不做。项目负责人确认取舍，设计和技术团队反馈缺口；反馈再写回需求，避免各自按理解开发。

flowchart LR
    A["初始想法"] --> B["用户与使用场景"]
    B --> C["本次范围与排除项"]
    C --> D["成功、失败与权限边界"]
    D --> E["可检查的验收条件"]
    E --> F["设计与技术评审"]
    F -->|发现遗漏| C

项目里曾在推进中补齐访问限制，也曾根据实际操作细化“修改”的含义。需求因此从功能名称变成行为规则；重大取舍仍由项目负责人决定。

3.2 从单张方案到可以交接的规则

设计稿需要说明窗口变化和操作状态；技术方案需要对齐数据、权限与错误含义。此前大屏留白、窄窗操作不可达等反馈，推动项目补充窗口规则和联合走查，而不是只验收一张画板。

方案明确到足以支持下游工作后再交接；不要求把所有未知问题提前解决。

3.3 按依赖拆分，在实际运行中汇合

共享规则由唯一编辑者维护，前后端各自实现。独立任务可以并行，依赖接口或数据决定的任务先后执行。团队主 Agent 整合内部结果，再交给其他团队联调。

flowchart TB
    A["已确认范围、设计与共享规则"] --> F["前端：页面与操作状态"]
    A --> B["后端：接口与数据行为"]
    A --> O["运维：环境与运行准备"]
    F --> I["真实环境联调"]
    B --> I
    O --> I
    I --> Q{"结果符合共同规则？"}
    Q -->|是| V["功能与视觉复核"]
    Q -->|否| R["定位问题归属与影响"]
    R -->|实现问题| F
    R -->|数据问题| B
    R -->|环境问题| O
    R -->|规则缺口| A

实际联调曾出现“同一数据在两个环境中结果不同”。团队核对数据记录、存储位置与运行配置后找到差异，再分别修正规则和环境。单个团队的测试通过，仍需在汇合处检查组合结果。

3.4 新反馈到来，更新受影响的部分

探索不会沿流程图一次走到底。项目负责人提出布局、存储或环境规则变化后，需要先判断影响，再继续已获授权的工作。

flowchart LR
    A["新反馈或现场问题"] --> B["确认影响与授权"]
    B --> C["更新对应事实来源"]
    C --> D["通知受影响团队"]
    D --> E["修正并定向复核"]
    E --> F["记录结果与剩余事项"]

需求变更回产品，视觉变更回设计，接口变更协调消费者；仍有效的结果继续复用。

3.5 用证据说明交付到了哪里

项目逐渐把“完成”拆成可核对的结论。各项检查覆盖不同问题，不能互相替代。

交付记录保留版本、环境、证据入口和未验证项。生产操作按实际授权执行；发布后再核对运行版本与用户路径。暂停后从当前任务续接，而不是重新解释整段历史。

4. 回到项目：一个“发布文章”的想法怎样展开

项目负责人最初希望博客能够发布文章，并选择先做产品方案与设计评审。这个目标没有直接变成开发任务：首期采用 Markdown 编辑与预览，支持修改和撤回，暂不加入评论、搜索、分类和定时发布。范围先缩到能够写作、维护和公开阅读的一条主链。

下面三个片段展示需求怎样在反馈和联调中继续成形。它们按问题归纳，并非严格连续的开发顺序。

先让各团队理解同一个目标

首页书架的早期方案被认为老套，与已有页面不协调。项目负责人随后把期待说得更具体：保留原有首页，在后面追加文章区域，每篇独占一行，显示标题、时间和摘要。

产品将反馈收敛为范围，设计修改方案，前端评估窗口变化与实现方式。方案被接受后才进入开发。这里的交接物既有设计稿，也有明确的保留项和展示规则，后续团队不必重新猜测“风格协调”是什么意思。

一个“修改”按钮，背后还有未说明的规则

支持发布后修改，还需要回答：后台保存了半篇改稿，访客是否应该立即看到？项目确定，重新发布成功前继续保留线上旧内容。

这个判断让各团队有了共同依据：产品区分保存与重新发布，设计展示待发布状态，前端处理确认和失败反馈，后端分别维护工作稿与公开内容。

flowchart LR
    A["访客读第一版"] -->|后台保存修改| B["工作稿更新<br/>访客仍读第一版"]
    B -->|重新发布成功| C["访客读新版"]
    C -->|撤回成功| D["后台可继续编辑<br/>访客不可读"]

Docker test 随后用同一篇文章检查了这条主链：保存不改变公开内容，重发整体替换，撤回后文章与图片不可匿名访问。联调检查的是共同规则是否成立，而不只是按钮是否能点击。

各自能运行，放到一起却出了问题

图片接入后，原生本地服务能读取的一张图片，在 Docker test 中却不可用。后端核对同一图片的数据记录、对象大小与内容校验值，发现两套服务共用测试数据库，却从不同存储路径读取：一边的对象存在，另一边的路径没有对象。

问题涉及测试环境的定义，后端无法仅靠改接口解决。产品确认两者属于同一逻辑测试环境后，后端统一路径规则，运维保留快照与旧对象、复制文件并更新配置，再分别检查实际读取。

sequenceDiagram
    participant B as 后端
    participant P as 产品
    participant O as 运维
    B->>B: 对照同一图片，定位存储路径差异
    B->>P: 共用数据库，是否应共用对象路径？
    P-->>B: 确认同一逻辑测试环境
    B->>O: 交接统一路径与配置要求
    O->>O: 保留数据、复制对象、更新测试容器
    O-->>B: 回报实际运行配置
    B->>B: 独立核对公开读取与权限

这次排查把一个环境中的局部成功，推进为共享规则、配置和实际运行结果的一致。项目负责人随后要求环境差异由显式配置提供，服务不再根据环境名称猜测存储位置。