9 月以来的复盘：从迷茫到全新认知的三个月
自 9 月份以来，投入 Wegic 2.0 的时间已经超过三个月。从最初的迷茫，到如今建立新的认知体系，这短短三个月的密度与变化，仿佛经历了一整年。借着这段沉淀期，也正好系统地回顾一下这段时间的成长与变化。
一、技术架构的复盘
提到架构，不得不将 1.0 与 2.0 做一个对比。
1. 1.0 的失败主要源于三个方面：
- 自定义数据结构与 AI 的训练语料不匹配，导致模型难以充分发挥能力。
- 上下文传递不足，影响任务的连续性与准确性。
- Workflow 过于呆板，缺乏灵活性，难以适应复杂应用场景。
2. 2.0 的架构改进
2.0 解决了上述问题，并进一步拥抱了 Agent 架构。 当然，当前的 Agent 架构并不能说是最优解，它依然是基于技术现状的 trade-off（权衡）。趁此也展开聊聊主流的 Agent 方式：
主流 Agent 模式
- ReAct（Reason + Act）模式 —— Cursor、Claude Code 等广泛采用
- PTA（Plan → Think → Action）模式 —— 许多 AI 工具的 Plan 模式基于此
- LangGraph（状态机 + DAG） —— 多智能体的可控执行架构
- Multi-Agent —— 多智能体协作执行
- Memory Agents —— 具备长期记忆机制
单一架构无法覆盖所有业务场景，因此仍需要在真实业务中不断实践、调整，并逐步形成适合自身的体系。这可能也是当前架构演进与敏捷迭代的最佳途径。
参考资料：
Towards a Science of Scaling Agent Systems
- 工具越多/环境越复杂，多代理系统的协调税越致命
- 单代理基线已经很高时（约 >45%），加代理往往收益递减甚至变负
- 多代理拓扑决定错误是“被压住”还是“被放大”
Token 效率
Introducing GPT-5.2 GPT‑5.2 的定价为每一百万输入 token 1.75 美元、每一百万输出 token 14 美元，对缓存输入有 90% 的折扣。在多项代理评估中，我们发现尽管 GPT‑5.2 的每个 token 成本更高，但达到同等质量水平的总成本却更低，因为 GPT‑5.2 的 token 效率更高。
Introducing Claude Opus 4.5 将努力水平设为中等，Opus 4.5 在 SWE-bench Verified 上达到 Sonnet 4.5 的最佳分数，但输出令牌减少了 76%。在最高努力水平下，Opus 4.5 比 Sonnet 4.5 的性能提升了 4.3 个百分点，同时使用的令牌减少了 48%。
二、团队协作方式的变化
最明显的变化是协作方式从传统“产研分离模式”向 敏捷迭代 转变。
从被动执行 → 主动探索
这种方式对 Wegic 2.0 的推进带来了显著好处：
- 想法可以快速验证和落地
- 研发周期缩短
- AI Coding 让一周拿下 Demo 成为可能
- MVP 能在一个月内上线
每个成员的主观能动性得到了极大释放。
如果问：“这样的协作方式是最好的方式吗？” 我的回答是： 至少对当下是合适的。大家能自由发挥，而不是被流程束缚。
未来随着 AI 能力提升，协作方式也会继续演化。也许未来每个人都可能成为 超级个体：从产品、研发到测试、运维都能端到端完成。
"虚"与"实"
我理想的协作方式可能是: Show me the demo.
三、AI Coding 对团队与个人的影响
从十月开始全面投入 Full-vibe Coding，我最直观的感受是：
1. 从 0 到 1 的效率极大提升
在 Demo 阶段，AI 基本能“你说什么就给什么”。
2. 但代码规模扩大后，需要更多主控
当项目变复杂后，AI 就不再“全自动”了，需要：
- 人来提前制定计划
- 主动 review AI 输出
- 必要时打断并调整
- 明确告诉 AI 实现方式
这是一个人与 AI 协同的新范式。
3. 个人心态也随之转变
从最初的“AI 无所不能”，到现在的“我来掌控 AI”。 越深入使用越清晰：
AI Coding 的生产力革命毋庸置疑，但代码质量的根本仍在于人。
比如：具备 Bad Smell 感知的程序员与没有这种意识的程序员，用同样工具产出的代码质量一定不同。
四、在 AI Coding 时代，程序员的核心竞争力
我认为至少包含以下几点：
- 编码与工程实践能力 小函数、SOLID、设计模式、TDD、DDD、重构原则等。
- 问题拆解能力（Trouble Shooting） 能够从大问题拆分成可执行的小单元。
- 全流程视野 不只写代码，还要理解产品、交互、数据、运营逻辑。
- 抽象能力 能从复杂系统中提取共性，建立模型。
- 底层原理理解 理解本质的人，才更能驾驭 AI。
五、关于后端能力集成的一些思考
关于是否让 AI 直接接管、部署、托管用户的后端能力，我目前的观点是：
现在还不是一个适合“自部署、全托管后端”的时机。 走第三方集成（例如 Supabase）可能是更好的选择，而不是自建一个 Supabase。
原因如下：
1. 后端是“隐形”的，需要逻辑能力才能正确构建
不像 UI 那样可视化，后端的维护与构建高度依赖抽象能力与逻辑推理，这是目前 AI 在复杂系统中仍未完全胜任的领域。
2. 业务规模会放大后端复杂度，而 AI Coding 迭代尚不足够
随着业务增长，后端面对的压力会指数级提升。AI 目前更多擅长“从 0 到 1”，但在“从 1 到 100”的长期演进上，稳定性与可控性仍有缺口。
3. 后端业务变化频繁，对代码的要求更高
后端的变动往往牵一发动全身：
- 血缘关系复杂
- 依赖关系深
- 代码上下文巨大（当前 AI 的上下文容量仍无法完全承载）
这对 AI 自动化改动提出了巨大挑战。
4. 业务数据的安全和风险不可忽视
让 AI 全托管用户的核心数据风险巨大：
- 数据泄露
- 权限问题
- 灰盒行为不可控
目前行业内都谨慎处理这一点。
5. AI 缺乏“操作性环境”来完成真实后端任务
后端不仅是写代码，还包括：
- 代码设计
- 数据库管理
- 权限体系
- 网络配置
- 部署 / 运维
- 监控与调优
现阶段 AI 可操作的环境远不足以支撑这些能力的完整闭环。
总结：不是不做后端集成，而是要走更现实的路径
简单的业务需求下，使用 Supabase 等第三方服务已足够满足大多数场景，并能保持安全、可控与高效。 未来随着 AI 能力与工具链成熟，“AI 全接管后端”可能会成为趋势，但至少 现在还不是最佳时机。
More Thinking, More Value