先恢复可信基线再谈重构

更新于 2026-07-29

**决定「重构项目」之前，先做一次架构与工作流审计，把现状冻结、边界确认 —— 因为要修的往往是契约，不是目录。**

目录已成形时，要的是 Contract Refactor 而不是 Directory Refactor

apps/    web · agent · worker · ai-workflows · feed-ingestion · admin
packages/ ai · application · db · queue · shared

这类边界一旦基本成形（且架构文档已明确记录 apps/agent = Agent Harness/Session/Tool Loop、apps/ai-workflows = 固定 workflow + cron、packages/ai = 模型/Provider/Usage、packages/application = 权限/事务/AiAction、packages/db = 持久化），先确认各模块是否真的遵守边界、环境是否隔离、部署是否稳定、功能能否端到端使用；只有审计发现严重错位时才移动代码。

要避免的循环：

为了让 Agent 能用 → 先重构整个项目 → 又重构协作层 → 又接入执行器 → 又改部署 → 一周后仍没有体验入口

Phase 0：先做 Baseline Matrix（基线矩阵）

第一个问题不是「加什么新工具」，而是：

现在 main 上哪些东西真的能运行？

能力LocalDevelopmentProduction验证证据
基础 Web / 登录 / 笔记 CRUD / Agent Chat / Tool 调用 / AI Workflow / Worker待确认待确认待确认URL、截图、完整对话、Action 记录、AiRun 输出、Job 日志

「待确认」必须靠证据填，不能靠读代码填。 同一个功能可能同时存在三份副本——代码里有的、服务器上跑的、数据库里留的——三份不同步时，只看代码就下结论会把人带偏；正确做法是用生产真实代码对生产真实数据做一次确定性验证，而不是「追查某个 key 是不是坏的」这类猜测（见 判断现状要看真正在跑的那一份）。

分两条线推进

  1. 产品与 Agent 功能形成一条最短可用链路（先有体验入口）。
  2. 同时重构协作层协议，但暂时不要深度绑定执行器 —— 外部编排工具应当只是 Replaceable Adapter（可替换执行器），个性化二开排在其后。

相关