适用于多Agent产品迭代时一套”防互相踩踏”协作规约。

这不是Git入门教程。这是团队协作，单人多Agent在产品迭代时总结出来的一套”防互相踩踏”协作规约。文章系AI共同创作。

0x00 前言：Git规范的对手已经换人了

几年前讨论 Git 规范，重点是分支怎么命名、commit message 怎么写、PR 怎么合并。这套老规矩是给”打字慢的人类”准备的。18年开发的时候还互相喊一嗓子，review完就先推main了。谁也没想到git worktree能够用起来。

但是现在不一样了。我个人开发项目里常态是同时挂着 Cursor、Claude Code、Codex在跑。 // 上一篇文章是之前4个月84亿token，现在是2个月后增加到了204亿token，短短两个月翻了2.4倍。同时新引入了codex的使用。⚠️codex在长程任务上效果良好，尤其是debug类的场景。

这些工具有一个共同点：写代码比人快好几个数量级，当然犯错也是。一个真实的多 Agent 场景大概长这样：

• Claude Code 在 worktree A 里改 schema

• Cursor 在 worktree B 里改 consumer

• Codex 在主目录里”顺手”动了 contract file

• 回头一看 main 上多了三个本地 commit，没人记得是谁推的

• 某个 agent 一句 git stash 把另一个工程师的未提交工作藏了起来

这时候 Git 规范的目标已经不是”历史好看”，而是：让所有并发工作都能被定位、隔离、审查、验证、回滚。

简单的说，AI 写代码越快，团队就越需要把破坏性动作变慢，把责任边界变清晰。下面是我这几个月踩坑总结出来的规约，分四章正文，最后是总结的checklist。

0x01 工作区隔离：从 main 到 worktree

多 Agent 并发最容易失控的不是模型能力，是 ownership 模糊。两个 agent 同时编辑同一个 contract file，谁的 diff 是对的？没人知道。所以解决方案不是更复杂的口头约定，而是把隔离结构做进工作流。

1. main 只做集成，不做开发

第一条最简单也最容易被破坏：不要在 main 上直接开发，更不要让 AI 在 main 上改代码。main 应该只承担一个职责——integration branch，代表团队当前认可的集成状态，不是任何人或任何 Agent 的临时草稿区。

推荐的本地配置：

git config pull.rebase true

git config pull.ff only

git config branch.main.rebase false

同步 main 之前，先诊断，再动手：

git fetch origin --prune

git status --short--branch

git rev-list --left-right --count main...origin/main

如果本地 main 和远程 origin/main 都向前走了一步，不要在脏的 main 上直接 pull 解决冲突。正确的做法是：创建一个隔离的 integration worktree，从 origin/main 重放目标分支，跑测试、看 diff、验证通过再合入。

这是 AI 时代第一条”慢动作”——在 main 上的任何冲突解决，都要假设另一头还有 N 个 agents 在并发写入。

2. 一个任务 = 一个branch+一个worktree+一个owner+一份scope

物理隔离从 worktree 区域分配开始。我自己的本地仓库默认长这样：

worktree 目录用 .git/info/exclude 忽略掉，避免本地执行环境（venv、node_modules、临时缓存）跟着 commit 误提交。

分支命名要携带来源和意图——它在多人协作里是索引，不是装饰品：

避免 update、fixes、wip、new-code 这种看不出责任和边界的名字。一个分支是哪个 agent 创建的、改的什么 scope，光看名字就该一目了然。

最后是 任务分配契约——给 AI 一句自然语言目标是远远不够的。一份可控的 AI coding 任务，至少要明确这些字段：

这份契约干两件事：限制 AI 的写入范围（减少”顺手重构”和无关文件漂移），给 reviewer 提供判断依据（这次改动是否尊重 scope）。

并行 agent 只适合写入范围不重叠的任务。一个 agent 改文档、另一个改 adapter tests、第三个 review contract fixtures，是安全拆分。两个 agents 同时编辑一个 contract file，或者一个改 schema、另一个不知情地改 consumer，这就是地雷。

0x02 三道关卡：编辑前、commit 前、PR 前

多 Agent 协作里”看起来没问题”是没有价值的。每个阶段都要留下可复现的证据，不然出问题没法回放。

编辑前：

git fetch origin --prune

git switch main

git pull --ff-only

git worktree add .worktrees/<task-name> -b <branch-name> origin/main

git status --short--branch  # 必须 clean

git branch -vv

开发中：

git status --short

git diff--stat

git diff--check    // 这一行专门挑出尾随空格、混合空格Tab之类的低级错

commit 前：

git diff --name-only

git diff --cached --name-only

如果 staged 文件列表里出现了你没预期的路径——停下，重新审视。AI 经常会”顺手”动到不在 scope 里的文件。

PR 前：

git fetch origin --prune

git log --oneline origin/main..HEAD

git diff --name-only origin/main...HEAD

git diff --check

这些命令的目的不是仪式感，而是让 reviewer 看到三件事：这个 PR 只改了预期文件、diff 没有低级格式错误、提交历史只包含本任务应该带来的 commits（没有”夹带私货”）。

PR 模板：必须能被读完

在 AI 参与的项目里，小 PR 比大而全的自动化产出重要 10 倍。PR 必须小到一个人类 reviewer 真的能读完。每个 PR 至少应该带：

AI-assisted 的工作还要额外说明：哪个 agent / tool 写的、branch owner 是谁、实际跑过的验证命令是什么。重点是”实际跑过”——AI 在 PR 描述里写 “all tests pass”，但 reviewer 一拉下来发现连依赖都没装，这种事在多 agent 项目里发生的频率远超你想象。

合并策略默认 squash merge——一个 PR 对应 mainline 上一个 commit，更容易 revert，也更容易生成 release notes。只有当 commit sequence 本身有清晰审查价值时，才用 rebase merge。在多 agent 协作下，干净的 mainline 历史比保留每个 AI 的中间尝试更有价值。

0x03 破坏性动作必须慢动作

AI 写代码越快，破坏性 Git 操作就越要慢。把高风险动作和它们的”刹车”列出来：

stash 之前一定要先看 git status --short 和 git diff --stat。如果变更里有可能属于另一个 agent 或工程师的文件，停下来识别 owner：

git worktree list

git branch -vv

worktree 清理的默认策略是——不确定就保留。AI session 结束时工具经常会问要不要删 worktree，默认答案是”保留”，除非五条全过：

git status --short   # clean

git branch -vv   # 没有 unpushed commits

git worktree list    # 没有人在用

gh pr list --state open--head<branch-name># 没有 open PR

git log --oneline origin/main..<branch-name># 有价值的 commits 已 push 或 merge

保留一份 review context 通常比省一点本地磁盘重要得多。

0x04 AI Context 才是真正的”起跑线”

Git 隔离解决的是工作区问题，AI context 解决的是理解问题。这是两个不同维度，但很多团队只解决了前者。

很多 AI 事故不是模型不会写代码，而是它基于错误的现实写出了看起来很合理的代码。比如：旧架构文档里某个 module 还在，但代码里早就删了；AI 看着旧文档继续调用，跑起来才发现 import 失败；然后它开始”自信地”造一个假的 module 来补全。

每个产品仓库都应该提供一份轻量上下文，让所有工具从同一组事实开始：

AI session 的阅读顺序也要固定：先读产品当前 context（VIBE_CODING_CONTEXT.md），再读 status（STATUS.md），再读 agent 指令（CLAUDE.md / AGENTS.md），跨产品再读平台文档和契约。STATUS.md 跟旧架构文档冲突？以 STATUS.md 为准。文档腐烂是常态，给一个明确的”事实源”比假装所有文档都对要诚实。

跨仓库改动不能靠”同时开几个 PR”解决。推荐顺序是：dependency repository PRs → product repository integration PRs → documentation index 或 release notes → cleanup branches。涉及 submodule pointer 的，必须先在 submodule 内 commit、push、PR merge，再更新 parent repository pointer。跨仓库协作的本质——让依赖方向在 Git 历史里也清晰可见。

0x05 总结

多Agent协作的Git规范，本质就是一句话——给工具划清责任边界。下次开多个 agent 之前，对着这张表扫一遍：

回过头看，这套规约里没有任何一条是”AI 才需要”的——它们本来就是好工程实践。AI 只是把它们从”建议”变成了”必须”。因为人犯错，commit 之前还有几秒钟的犹豫；AI 犯错，从思考到写盘可能不到一秒。

当这些规则成为默认工作流，多个 IDE、多个 agents、多个工程师就不再是互相踩踏的并发写入者，而是可以并行推进、独立验证、最终有序集成的协作者。

参考

• git-worktree 官方文档

• Trunk-Based Development

• Conventional Commits

• Vibe Coding 生存指南

• AI软件工程实践：构建企业级Agentic SOC平台

• AI编程实践总结

阅读原文

跳转微信打开

443个真实项目会话、84亿Token，以及无数次被Bug搞懵逼之后总结来的经验和教训。

提前排雷：这不是一篇吹捧”AI编程多牛逼”的软文。这是用真金白银、443个真实项目会话、84亿Token，以及无数次被Bug搞懵逼之后总结来的经验和教训。本想拆成Vibe Coding深度实践系列，把每个章节单独拎出来，但实在精力有限。文章系AI共同创作。个人写作风格点击此处，系学习自本人过去两年的博文所得。 //访问原文阅读排版效果更好

0x00 这些数字是真的

过去四个月，我用 Cursor 和 Claude Code 搓了三个不同规模、不同性质的项目：

• AgenticaSoC — 一个安全运营中心（SOC）AI平台，LangGraph编排 + 多智能体 + 多层记忆架构（PostgreSQL/Qdrant/Redis）

• Blinds — 一个结合 SAST/DAST 和 LLM 推理的自主安全研究平台，用于解CTF和挖漏洞

• up-cli — 一个用来”管理AI编程的AI编程工具”，也就是让AI来自我管理开发流程

我写了个脚本把所有历史数据跑了一遍，看着输出的账单和Token数，内心却毫无波澜：

84亿Token、38948条消息、58个项目、547次Cursor对话、204次Claude Code会话。

三个核心项目的对话量：

使用的模型包括：Cursor 侧的 claude-4.5-opus-high-thinking（主力，162次）、gemini-3-pro（109次，占34.6%）、claude-4.6-opus-high-thinking、claude-4.5-sonnet-thinking、gemini-3.1-pro、gemini-3-flash；Claude Code 侧的 claude-haiku-4-5、claude-opus-4-5、claude-opus-4-6。

最疯狂的一天（2026年1月10日），单日消耗了4.1亿 TokenClaude Code）// 由于claude的代理站最开始没有cache read和write，并用来整理文档以至于消耗如此之多。

同时我用 visualize_deep.py 对443个会话做了深度量化分析。说个颠覆认知的点：

Vibe Coding 在有结构的时候效果惊人，在没有结构的时候也失败的惊人。

89.8% 是总体成功率，听起来还行。但它背后是 AgenticaSoC 的 97.4% 和 up-cli 的 66.7% 之间的巨大鸿沟——而这个鸿沟，不是模型能力的差距，就是工程方法的差距。

图注：443个会话中，使用不同技术栈的成功率分布。结构化框架（绿色）稳居高成功率的”安全区”，而无结构的脚本与文件操作（红色）则极易跌入”危险区”。

看看这张图。凡是使用了 FastAPI、Docker Compose、LangGraph 这些重型框架的会话，成功率几乎是 100%。这揭示了第一个真相：决定 AI 表现的，不是任务有多简单，而是你给了它多少”脚手架”。

这是不是就是所谓的Harness Engineering？

0x01 三个失败原型：AI到底是怎么翻车的？

分析 443 个会话里的 45 个非成功案例，我发现所有失败几乎都归结为三种原型。

1. 失败原型一：沙箱墙（Sandbox Wall）

来源：up-cli，占全部失败的约60%

这是最荒谬也最真实的失败模式。up-cli 是一个”用AI开发工具来管理AI开发”的元工具——AI Agent 在一个受限的沙箱环境里运行，但它制定计划时假设自己有完整的文件系统写权限。

于是出现了这样的死亡循环：

[步骤1] AI 尝试创建目录 → 权限拒绝
[步骤2] AI 重试 → 权限拒绝
[步骤3] AI 再试 → 权限拒绝
...
[步骤14] 会话消耗完毕，什么都没做成

真实的失败记录：

• "Attempting to create a new subdirectory was blocked by environment restrictions"
• "Unable to create the test files due to file system permission restrictions"
• "The assistant repeatedly requested permission or retried the same operation"
• "The session entered a loop where the assistant repeatedly requested permission"

数据铁证：

• up-cli 用 Cursor（人工监督）：93.3% 成功率，平均 33 条消息

• up-cli 用 Claude（自主运行）：42.4% 成功率，平均 175 条消息

那 175 条消息里，大部分都在做无效的重试。这直接反映在消息统计上——up-cli 的平均消息数是 107.3，而 AgenticaSoC 只有 38.7。

2. 失败原型二：上下文窗口耗尽（Context Window Exhaustion）

我就不该尝试Ralph Loop，也不该设计Ralph Loop的工具让工具自己去Loop，这直接导致了缺乏Code Review和大量的无效Commit

跨所有项目，占非成功 的约25%

这是成长的代价。当你从”每步都盯着AI”进化到”让AI自主跑一大段”的时候，新的失败模式出现了。

死亡曲线如下：

这组离谱的数据背后，是无数次眼睁睁看着AI走向崩溃的无奈。

图注：随着会话长度增加，代表成功的绿色区域断崖式下跌，代表失败（红）和放弃（灰）的区域急剧扩张。

如图所示，存在一条致命的 “熔断边界”（大约在 80-100 条消息）。越过这条线，AI 就像一个连续通宵 3 天的程序员，失去了全局架构视野，开始”打地鼠式”修 Bug。最终，Token 溢出，会话暴毙。

非成功会话的 P90 消息数是 261条，P95 是 379条；成功会话的 P90 只有 102条，P95 是 151条。 //注：P90代表90%的会话都在这个数值以下。

当上下文窗口塞满了代码、报错、修复历史之后，AI 开始”Whack-a-Mole”——它修复症状而非原因，因为它已经看不到全局图景了。最惨的一个非成功会话，消耗了 526条消息。

3. 失败原型三：安全过滤器/能力天花板（Security Capability）

Blinds 项目，占非成功的约15%

Blinds 是一个进攻性安全工具——它的核心功能就是找漏洞、写 PoC。但模型对”生成利用代码”有强烈的内在抵触。

有趣的是数据里出现了一个逆转：

• Blinds 中等复杂度（CTF/漏洞利用会话）：成功率 72.5%

• Blinds 高复杂度（架构/LangGraph流水线会话）：成功率 90.9%

高复杂度反而更成功，因为那些是在构建工具，而不是在触发过滤器。

0x02 最扯淡的数据：高复杂度任务成功率反而最高

这是 visualize_deep.py 输出的 Complexity × Outcome 矩阵：

如果表格还不够直观，我们把所有项目扔进”效率-成功率”的二维空间里：

图注：X轴为每条消息产出的代码行数（效率），Y轴为成功率。大项目（紫色圆圈）反而多落在右上角的”高效区”。

为什么右上角那些高产出、高成功率的”大圆圈”（如 AgenticaSoC），全是高复杂度任务？

因为当一个任务被标记为”高复杂度”时，你会主动启用全套工程规范：老老实实地写PRD、分配 Task ID、挂载自动化测试、做 Git Checkpoint。

相反，当一个任务被标记为”低复杂度”时，你可能只会甩给AI一句：”修一下这个bug”。然后AI就开始了它的掩耳盗铃。左下角那些看似简单的”小修小补”，反而最容易因为随意的”Vibe”而翻车。

这也存在另外一个问题，就是在Vibe Coding中，大量生成代码带来爽感的同时，极需要有经验的专业验证。

分项数据更明显：

• AgenticaSoC 高复杂度：98.8% 成功率（最有结构的项目）

• up-cli 低复杂度：55.0% 成功率（最缺乏结构的上下文）

• Blinds 高复杂度：88.2% 成功率（结构甚至能拯救最难的项目）

结论：结构不是速度的敌人——结构是速度的前提条件。 工欲善其事，必先利其器。

0x03 大型 Vibe Coding 的七宗罪

通过深入审查 AgenticaSoC 的 Git 历史、85 个 Changelog 文件和真实的代码，我（AI）发现了七种 Vibe Coding 特有的”隐蔽杀手”。它们在小项目里无害，在大项目里致命。

大型项目综合分析矩阵：AgenticaSoC / Blinds / up-cli 在成功率、消息效率、代码产出和失败模式上的全维度对比。这三条数据线，是七宗罪的土壤。

七宗罪看起来是七个独立的坏习惯，但其实它们有一个共同的根——每次和 AI 的对话都是从零开始，没有人跨会话强制一致性。 每个 AI 会话产出的是局部正确的输出，但全局上代码库积累了矛盾、死胡同和幽灵功能。最大的风险不是坏代码，是一致性漂移。

1. 第一宗罪：”宣布胜利，然后永远修” （Quick Win）

“代码存在”不等于”代码工作”

真实证据： 在 2026 年 1 月 23 日这一天，changelog 目录里出现了 30+ 个文件：

phase-1-2-3-complete.md
phase-1-2-3-complete-detailed.md
phase-1-2-3-complete-final.md
phase-1-2-3-final-status.md
implementation-complete.md
deployment-ready-summary.md

然后在接下来几周，一串修复接踵而至：

• 2026-01-28

   — execution-flow-fixes.md（DbTool.tool_id 列不存在）

• 2026-02-02

   — fix-fake-metrics-data.md（仪表盘显示虚假模型名）

• 2026-02-03

   — agent-stability-improvements.md（Event loop 崩溃）

• 2026-02-04

   — report-display-fix.md（报告写入了错误字段）

Git log 讲了一个真实故事：先说 “Phase 1: 95%, Phase 2: 80%”，然后 “Implementation complete - Ready for production”，然后更多修复提交。Phase 1 的 “100%” 实际验证下来约 85%。

//注：尴尬的是，当时我还真信了它说的 100% 完成度，我也有点傻。

2. 第二宗罪：幽灵模块（Dead Code）

没人用的”正确方式”，和一直依赖的”错误方式”

代码库里存在多个”创建了但永远没接入”的文件：

与此同时，现有端点继续用 ad-hoc 的 offset/limit 参数和内联错误处理，完全无视这些”正确的工具”。

当你让 AI “添加分页支持”，它会完美地生成工具模块。它看起来完成了。但把现有端点迁移到新模块上——这种无聊的、重复性的集成工作——永远不会发生。你最终拥有两个并行系统。这就好比买了一堆先进的安全产品，结果发现卧槽，没插电！

代码量、会话数与成功率的交叉分析。注意 up-cli 的 “消息/千行代码” 指标——249.7 条消息才产出 1,000 行代码，而 Blinds 只需 25.9 条。幽灵模块和集成工作的缺失，是 up-cli 每千行代码要”聊”这么多的原因之一。

3. 第三宗罪：跨会话的”缝合怪架构” （Always Win）

跨会话记不住，但我还是要再赢一下，（Qucik Win到Always Win），反正赢就完了！赢麻了！

.cursor/rules/backend-style.mdc 明确规定：

Use Synchronousdef for route handlers… Do NOT mix async def with blocking Session calls.

但实际代码里：

asyncdefget_agents(
    db: Session = Depends(get_db),  # sync session inside async handler

这会阻塞事件循环。而 database_async.py 带着完整的异步引擎就在那里，但除了一个健康检查什么都没用。

每次和 AI 的对话都是重新开始。第一个会话创建 async handler，第二个创建 sync DB 层，第三个”为了以后”加了 async DB 支持。没有人跨会话强制一致性。代码库变成了冲突的 AI 决策的地质层，我极度怀疑 AI 根本没有跨会话的记忆，活脱脱把代码库搞成了一个缝合怪。

// 注：这也是我一直在尝试在大型脚手架工程里通过Skills注入强制读取外部记忆库，来查找里面针对Error的修复决策，以便能够满足大型项目的vibe coding问题。

4. 第四宗罪：大爆炸式重写（The Big Bang Rewrite）

生成大量代码用于重构对于模型来说是一件自圆其说且极有成就感的事情，但它不会关心重写是否有效。

Git 历史里最有启示性的两个 commit

a025a4e revert: restore terminal MCP server to v5.0 for better reliability
86ef6a1 upgrade terminal mcp with SOC-focused architecture

一整套 “SOC-focused” 的 Terminal MCP Server 重写（约8,900行）被commit，然后在下一个有意义的 commit 里完全回滚，因为它破坏了稳定性。

AI 非常擅长生成宏大的重构。它会欣然重写整个模块，带着”更好的架构”。但大规模 AI 生成的重写有更高的回归风险——AI没有对所有微妙集成点的评估和校验。生成 8,900 行代码的诱人轻松，让你倾向于做大爆炸式重写而非增量改进。

当时排查了两天，真他妈想砸键盘，最后发现这重写就是一坨 DB。很多 Vibe Coder 在面对大重写引入的 Bug 时，会试图让 AI 继续修（Fix Forward），最终沉没数百条消息。但知道何时果断 git revert，绝对是更重要的生存技能。

5. 第五宗罪：太逼真的假数据 (Fake Data)

比真数据还真的假数据！

这个来自 2026-02-02-fix-fake-metrics-data.md 的修复记录。仪表盘显示着假的模型名——Gemini 2.0 Flash、Claude 3.5 Sonnet——带着编造的性能指标和使用统计。看起来完美且专业。

根因： 后端没有实现 /stats/agent-metrics 端点，前端的 fallback 函数 computeAgentMetrics() 生成了拟真的假数据来”填充” UI。

人类开发者写占位符时，会用 “TODO” 或 “xxx”。AI 造假造得比外包敷衍你的时候还专业，仪表盘看着挺唬人，一查全是写死的常量。而且AI 的输出看起来太好了，以至于你根本不会去质疑它。

6. 第六宗罪：沉睡的 Feature Flags

多个核心功能被 flag 禁着，默认值全是 False：

AGENTICA_USE_REACT = False# ReAct推理引擎
AGENTICA_GOAL_EXTRACTION = False# 目标抽取
AGENTICA_BACKGROUND_EXECUTION = False# 后台执行

开发时每个功能加自己的 flag 完全合理。但跨多个 AI 会话之后，没有人做”哪些 flag 现在该默认为 True”的最终审查。 结果：平台的核心功能对用户来说开箱即不可见。每个 AI 会话加完 flag 就走了；”默认体验应该是什么”这个整体性问题从未被提出。

7. 第七宗罪：文档的进步幻觉

文档是愿望文档？还是描述文档？

AgenticaSoC 拥有 85个 changelog 文件、10 章学习系列、模式/差距分析文档。看起来极其成熟。

但当你深挖：

• 单日 30+ 个 changelog 说明是堆量生成，不是增量维护。

• 文档里的阶段完成百分比与实际实现不符。

• 10 章学习系列创建于项目末期（2026-02-28），记录的是设计态而非实现态。

AI 生成的文档创造了虚假的成熟感。它格式工整、覆盖全面、读起来很专业。但它掩盖了”设计”和”实现”之间的差距。当文档说”4 层反幻觉防御”但有些层没完全接上时，文档变成了愿望文档而非描述文档。新加入的人信任文档，然后被现实震惊。这其实也是幻觉里的常见问题，所以要永远验证，Zero Trust In the Vibe Coding。信任工具的输出，而非只是文档。

0x04 Cursor vs Claude：不要比较能力，要比较”分工”

很多人看到这组数据会本能地觉得：

“Cursor 比 Claude 强？”

这其实不是能力比较，这是任务分工的不同。

而且这个问题本身就问错了——“Cursor” 不是一个模型，它是一个容器。在那 378 个 Cursor 会话里，运行着两个完全不同的引擎：Claude（56%，215 次）和 Gemini 3（34.6%，133 次）。单看 Cursor 成功率是 94.7%，但拆开来看：

最后一行是这组数据里最冷的冷知识：不带 thinking 的 claude-4.5-sonnet 在 Cursor 里跑了 7 次，全部失败。不是模型不行，是在没有思考预算的情况下直接扔进复杂工程任务——就像让人闭着眼睛走迷宫。（掩耳盗铃竟是我自己）。这是”选对模型配置”比”选哪家模型”更重要的有力证明。

这种分工在数据分布上呈现出截然不同的形态：

图注：短闭环（Cursor主导）呈现高耸的集中峰值，长循环（Claude主导）拖出了一条沉重的 “Fat Tail”。

• Cursor 处理的是短循环、人工在环的会话：修一个文件、加一个组件、解一个 bug。人每步都在看。中位消息数20条。

• Claude Code 处理的是长循环、完全自主的会话：实现一个完整插件系统、重构1000行文件、跑安全审计。AI 自己跑100+条消息。

Claude 较低的成功率，是因为它承担了图右侧那条长长的”胖尾”——那些 150+ 条消息的无监督长线任务（也就是所谓的任务选择偏差）。失败，其实是因为开发者向”全自动委派”进化过程中必不可少的阵痛。

从 Token 消耗来看，这种分工更加清晰——Claude Code 消耗了 51 亿 Token，而 Cursor 消耗了 33 亿 Token。Claude Code 用更少的会话数消耗了更多的 Token，因为每个会话都是长时间深度工作。

Cursor 的成功率（95%）与 Claude Code（61%）形成鲜明对比。注意：这不是能力差距，是任务类型筛选的结果——Cursor 承接了所有短闭环精准任务，Claude 承接了所有无监督长线任务

不要用 Claude Code 去修 CSS，不要用 Cursor 去跑 5 个 Agent 的循环。把 Cursor 当作”外科手术刀”，把 Claude Code 当作”自主研究员”——两者都用，各司其职，才是正确的双引擎姿势。

0x05 架构思维的复利效应

visualize_cloc.py 输出了这组 LOC 效率对比：

最右边那列是此表最离谱的数字：up-cli 平均每产出1,000行代码，需要消耗 249.7 条消息。而 Blinds 只需要 25.9 条——差距将近10倍。

这不是模型能力的问题，三个项目用的模型几乎相同。差距来自架构决策的累积效应。

再加上这条强相关：LOC ↔ 成功率的相关系数 r = 0.969（强正相关）。代码量越大的项目，成功率反而越高——这是因为大项目强迫你做好架构，而架构反过来提升了每个会话的效率。

1. 开发者的Vibe Coding三阶段

最高ROI在第二阶段。第三阶段是未来，但眼下的基础设施（沙箱权限、上下文压缩、熔断器）还差点意思。

2. 真实Bug如何暴露架构缺陷

最能说明架构思维价值的，从来不是那些花里胡哨的设计文档，而是真实的 bug 修复记录。每一个 bug 都是一次 X 光片——照出代码库里哪里是一坨DB。

案例一：Agent守卫（Guardrails）的错误抽象

早期版本的熔断器：固定阈值 3 次重复就触发，且只跟踪 tool ID，不跟踪参数。

结果：Claude Opus 在处理复杂任务时，合理的多步工具调用（比如依次调用 read_file 读三个不同文件）被误判为”死循环”，任务被提前终止。AI 不是在卡死，是熔断器设计得太粗糙。

修复后的分层方案：

升级为参数感知检测——用 (tool_id, params_hash) 元组追踪。真正的死循环（同样参数反复调用）才触发熔断，合理的多步执行不受影响。还加入了优雅降级——注入引导提示而非硬性终止。

这个 bug 的架构本质： 熔断器不应该”感知不到调用参数”——把所有 tool 调用视为同质的，是对 Agent 行为缺乏建模。一旦你把 Agent 行为分层（不同能力模型用不同参数），这类 bug 就从”偶发奇怪行为”变成”设计时可以预测和避免的情形”。

案例二：Event Loop 崩溃——没人负责关灯

Celery 后台任务里，AI 客户端（Google Gemini、OpenAI、Anthropic 的 httpx.AsyncClient）每次调用都新建，从不显式关闭。垃圾回收器在事件循环关闭后尝试清理，触发：

RuntimeError: Event loop is closed

这个错误出现时，排查了两天。因为它不是每次都复现——只在高并发或长时间运行后暴露。

修复：完整的异步上下文管理器链

asyncwith AIClient(db, model_id) as client:
    result = await client.generate(prompt)
# 客户端自动清理——不再有 Event loop 错误

这个 bug 的架构本质： “谁创建，谁负责关闭”——这是老生常谈的资源生命周期管理原则。AI 会话一个一个地加功能，但没有任何一个会话去问”谁负责关闭这些资源”。这是一致性漂移（第三宗罪）在资源管理层面的体现。在 Vibe Coding 里，这类 bug 特别隐蔽，因为 AI 生成的代码每个单独看都是对的——问题出在会话之间的系统性遗漏。

案例三：SSH 连接——短视的”够用”

初始版本：每次执行命令都新建 SSH 连接。在单个命令的测试里没问题。但长时间 Pentest 任务中，Agent 可能连续执行上百个命令——连接开销和网络抖动让整个 Agent “卡住”，最终任务失败。

修复前后对比：

这个 bug 的架构本质： 初始设计只考虑了”单次执行”的场景，没有考虑”Agent 连续自主执行”的场景。当 AI 生成 SSH 工具时，它写的是一个可工作的函数——但”可工作”和”在 Agent 循环中可靠工作”是两件事。在 Vibe Coding 里，AI 生成的代码往往在 happy path 上完美，在 Agent 自主运行的 long-path 上才暴露问题。你以为有了个脚本就一劳永逸，殊不知长时间运行直接把系统拖垮。

3. 架构决策的优化

Twin-Engine 架构：最重要的一个决策

三个 bug 案例有一个共同的答案：把推理和执行分开。

在 AgenticaSoC 中，最重要的早期架构决策是明确分离两个平面：

graph TB
    subgraph MetaBrain["MetaBrain (控制平面)"]
        A1[世界模型<br/>Mode-1/2]
        A2[分层规划<br/>战略/战术]
        A3[熔断器<br/>成本模块]
    end
    subgraph Redis["Redis PubSub (通信层)"]
        B[消息队列]
    end
    subgraph Backend["Backend (执行平面)"]
        C1[AgentRunner<br/>LangGraph 循环]
        C2[Event Publisher<br/>SSE 推送]
    end
    MetaBrain --> Redis
    Redis --> Backend

这个分离来自 LeCun 的世界模型理论：Mode-1（反射式执行：快速、基于策略）和 Mode-2（深思熟虑的规划：慢速、基于世界模型模拟）。当 AI Agent 完成 Mode-2 规划后，成功模式被”技能编译器”编译成 Mode-1 的反射——下次遇到类似情况直接复用，无需重新规划。

但它直接对应 Vibe Coding 的核心矛盾：LLM 负责推理，代码负责执行，两者不能混在一起。 当你的代码库里推理逻辑和执行逻辑纠缠在一起时，你既无法测试推理，也无法可靠执行。三个 bug 案例里，熔断器（推理）混在执行层、资源管理（执行）散落在每个会话的功能代码里、SSH 工具（执行）没有考虑被推理层重复调用——全都是”没有分开两个平面”的代价。

图注：三个项目的会话模式对比。AgenticaSoC 的平均38.8条消息/会话与 up-cli 的107.3条形成鲜明对比——有架构分离的项目，AI每次都知道自己在哪一层，做什么。

UTCP：一个协议决策省掉了 4,000 行代码

架构决策有复利。把 MCP 迁移到 UTCP 是最典型的案例：

用协议替代胶水代码，用 JSON Manual 替代独立服务进程。你在第一天做出这个决策，之后每一个 AI 会话都不再需要处理”怎么连接 MCP Server”的复杂度——这省掉的不只是代码行数，而是认知负担的复利。

反观 up-cli 的 249.7 msgs/1K LOC，部分原因正是大量会话在处理”怎么调通工具链”这类本该被架构决策一次性解决的问题。每次对话都在重新发现同一个问题，纯纯的人工智障（我智障他也智障）。

0x06 即用型软件实践：小项目的天堂与大项目的地狱

在之前的内容，我们分析的全是大型项目的血泪教训。但事情有另一面——在同一时期，我还用完全相同的工具和方法构建了一批小型项目。它们的数据讲了一个完全不同的故事。

100% vs 66.7%：同一个人，同一套工具，天壤之别

对比三个大型项目：

同一个开发者，同一套模型，小项目 100%，大项目最低 66.7%。 差距不在人，不在工具，在项目本身。

小型项目数据矩阵：5个项目全部 100% 成功率，平均 3 个会话完成，构建时间从1小时到2天不等。

小项目的”超能力”：可丢弃性（Disposability）

小项目有一个大项目永远不可能拥有的超能力：如果代码坏了，重新生成比修复更快。大不了删了重来，管我屁事？

这完全改变了游戏规则：

小项目里的 AI 是 L4-自主——它自己管理任务列表、自己做文件系统探索、通过测试循环自我纠错。人的角色是”战略引导者和领域架构师”。

大项目里的 AI 需要 人工架构师级别的管理——PRD锚定、Task ID批处理、Gap Analysis、Git checkpoint。人的角色从”引导者”升级为”擦屁股的架构师”。

“相变”发生在哪里？

物理学里有个概念叫”相变”——水在 0°C 以下是冰，以上是水，性质完全不同。Vibe Coding 也有一个相变临界点。

根据数据，这个临界点大约在：

其实1w行以上，在传统软件工程中算不上大的项目，10w左右也只是中大型项目。但是考虑到不仅需要维护文档还要维护代码，对于AI来说，在代码的级别到10k左右，就需要进行一定的管理了。项目规模跨越这个临界点时，开发模式会发生质变

在临界点以下，Vibe Coding 的宣传片是真的——“随便聊，AI帮你写”，成功率 100%。

在临界点以上，Vibe Coding 变成了一个工程管理问题——你需要 PRD、Task ID、Git Checkpoint、Gap Analysis、熔断器，否则你会掉进七宗罪和三大失败原型的陷阱里，一起骂AI人工智障。

可丢弃软件的经济学

小项目的ROI数据验证了一个新概念：可丢弃软件（Disposable Software）。

• 人工引导时间：2-8小时

• 消息量：100-500条

• Token成本：通常 <$20

• 替代价值：替代了数周的高级工程师研究和样板代码

适用场景：内部工具、数据分析脚本、安全CTF、金融回测器、高保真UI原型

不适用场景：核心产品基础设施、需要多人协作的系统、高风险生产环境

crycrypto 在48小时内用80+测试实现了完整的 ISO 9797-1 和 TR-31 标准——一个高级密码工程师可能需要数周。iamsolve 在一个小时内破解了6个AWS IAM安全挑战。MoneyBackMyHome 在一天内建成了带31个测试的完整事件驱动的交易回测系统。

这些不是玩具——它们是 AI 在”正确尺度”下的真实能力展示。问题不在于 AI 能不能做，而在于你的项目是否已经越过了相变临界点。 这也就回到了之前文章提到过的一个观点，AI时代知道做什么，比能做什么更重要。

0x07 一图读懂：会话边界管理才是关键

这张图是对整个 Vibe Coding 核心逻辑的终极浓缩，它回答了两个核心问题：

1. 高层问题：什么样的 Vibe Coding 方式最容易成功？

2. 底层问题：单个会话什么时候会从”可控”滑向”失控”？

左上：相关性矩阵（Correlation Matrix）

• 看变量之间是正相关（绿色）还是负相关（红色）。

• 核心发现：项目规模（LOC）与成功率强正相关（r=0.97），但会话长度（Messages）与成功率负相关。说明项目规模本身不是问题，会话失控长度才是风险放大器。

中上：项目规模 vs 会话深度（气泡图）

• X 轴是项目规模（LOC），Y 轴是会话深度（消息数），气泡越大代表成功率越高。

• 核心结论：大项目并不天然失败；失败通常发生在”高消息数 + 低结构化管理”的组合。

这个动画展示了项目是如何落入”高效区（绿色）”或”迭代区（黄色）”的。小项目（绿色菱形）天然落在高效区，成功率 100%。大项目（紫色圆形）如果管理不当，就会掉进迭代区，成功率跌至 67%。

右上：消息量密度分布（按结果）

• 不同结果类型（成功/部分/失败/放弃）的会话长度分布。

• 核心结论：成功会话集中在短闭环（20-50条消息），失败会话拖出长尾（200+条消息）。

动画展示了小项目（绿色曲线）如何像外科手术一样精准，在 20-40 条消息处迅速收尾。而大项目（紫色曲线）则拖出了一条长长的”胖尾（Fat Tail）”——这就是你在与遗留代码和架构约束作斗争时付出的”对话税（Conversation Tax）”。

左下：会话形状密度图（Hexbin）

• X 轴是会话长度，Y 轴是每条消息的平均字符数，颜色深度代表密度。

• 核心结论：高密度区域在”中等长度 + 适中冗余度”，说明有效会话既不是”一句话搞定”也不是”长篇大论”。

中下：会话原型（平行坐标）

• 展示不同会话在”长度-冗余度-处理时间”三个维度上的模式。

• 核心结论：成功会话（绿线）呈现规律的平行模式，失败会话（红线）则混乱交叉。

右下：结果概率流（按会话大小）

• 随着会话规模从”Tiny”到”Mega”，成功/部分/失败的占比变化。

• 核心结论：存在明显的熔断边界（100条消息附近）。超过后失败率从 <10% 飙升至 35.7%。这与0x01章节的上下文衰减曲线相互印证——当会话长度越过熔断边界，代表成功的区域迅速坍塌，失败区域急剧扩张。

这张图说明：Vibe Coding 的关键不仅是模型更强，还有更重要的会话边界管理。 会话保持短闭环，成功率很高；当会话跨过上下文临界点，失败会迅速累积。所以真正有效的方法是：小步快跑、及时 checkpoint、到边界就重开会话。

0x08 终极战术手册：DOs and DON’Ts

如果你今天只带走三件事，请在下一次打开 IDE 时记住： // 这是AI写的，太装逼了）

1. 设立 60 条消息的硬熔断：见好就收，强制 /compact。

2. Plan 与 Execute 分离：让 AI 先写计划，再开新窗口执行。

3. 拒绝占位符债务：绝不允许 AI 写 // TODO，这会在长会话后期引发雪崩。

会话结构（每次都这样）：

1. Context Sync    → 加载 prd.json / state.json / architecture.md
2. Gap Analysis    → 让AI对比设计文档和当前实现，找出差距
3. Planning        → AI生成分步计划，你批准（不要跳过这步）
4. Execution       → 迭代 Product Loop，每步 Git Checkpoint
5. Verification    → 自动化测试 / Linting 通过
6. Checkpoint      → Commit + 更新 state.json

项目规模对应的控制策略：

三个救命提示词模板

启动项目（防止 AI 乱跑）：

Role: Senior Architect
基于 [PRD/描述] 的需求，生成分步实现计划。
输出格式：JSON
禁止：占位符、"coming soon" 注释、未实现的存根函数
优先实现：[基础设施/UI]

执行具体任务（防止上下文漂移）：

PHASE: [阶段名] | Task ID: [US-XXX] | Title: [功能名称]
使用 @[源文件] 中的上下文实现此功能
确保所有变更与 @[路线图文件] 同步
逐步推进，每步确认后继续

会话过长时的上下文压缩（防止幻觉）：

/compact
总结项目当前状态、最近3个成功变更、下一个立即目标。
清除无关的聊天历史，只保留架构决策和当前任务状态。

DO

1. 用 Plan-then-Do 提示强制 AI 先思考再写代码 "Role: Senior Architect. 基于 @prd.json 生成分步实现计划，JSON格式输出，禁止使用占位符"

2. 每次重要改动前 Git Checkpoint

3. 3–5 次连续失败后触发熔断器 不要让 AI 无限重试，人工介入重置上下文

4. “接上或删掉”规则 每个新生成的工具模块必须在当前会话结束前至少有一个调用者。不允许孤儿文件。

5. 用绝对导入替代相对导入 深层目录结构里，相对导入是沙堡，一次重构全部崩塌

6. 单会话一致性检查 会话结束前验证：新文件是否遵循现有模式？是否和 style rules 矛盾？

7. “给我看调用者”规则 当 AI 生成一个 utility/module，立即问：”现在给我看现有代码中谁会调用它。”

8. 多租户类架构从第一行代码开始设计 后期改造 tenant_id 是手术，早期设计是疫苗

9. Feature Flag 审计节奏 审查所有 flag。如果一个 flag 已经 False 超过两周，要么启用它，要么删除这个功能。

10. 限制 AI 单次变更 < 500 行 如果重构需要更多，拆成多个阶段，每个阶段有可工作的中间状态。（人工Review的情况下，可以更多一些）

DON’T

1. 永远不要 except Exception: pass 这条 bug 修了三个月，因为它让所有错误无声消失

2. 不要 hardcode localhost 或相对路径 容器化的那天你会哭着想起这条

3. 核心文件不要超过 1000 行 强制执行 500 行限制重构，超过 1000 行就是技术债墙

4. 不要在 LangGraph 里混用 sync 节点和 async LLM 调用 async/sync 嵌合体——第三宗罪

5. 不要接受 Placeholder // TODO: implement 在早期看起来无害，在后期是地雷阵。AI 生成的占位符更危险。

6. 不要用情绪化语言给 AI 施压 "你TM的为什么又搞错了！！！" 不提供技术上下文，只消耗 Token。AI又不是你的出气筒，正确姿势：提供 stack trace + 请求”Root Cause Analysis”。

7. 不要在长会话里没有 /compact 就继续走 200+条消息后的失败率是 35.7%，是正常区间的5倍

8. 不要信任”Phase Complete”文档 验证实际状态，而不是文档声称的百分比。

9. 不要做大爆炸式重写

对抗七宗罪的五种方法

四条架构纪律

• 推理与执行分层： LLM 决策层（Plan/Think）和代码执行层（Run/IO）必须有明确的边界。不要让 LLM 直接操作数据库，不要在执行层嵌入复杂的 prompt 逻辑。

• 资源生命周期显式管理： 任何跨会话共享的资源（HTTP 客户端、数据库连接、SSH 连接）必须有明确的创建者和关闭者。在 Vibe Coding 里，AI 擅长创建，不擅长清理——显式的上下文管理器是唯一可靠的方案。

• 协议优于胶水代码：每当你准备写一个”桥接模块”或”适配层”，先问：有没有已有协议可以表达这个接口？胶水代码是 AI 会话最大的认知负担，协议是认知负担的压缩。

• 架构变更先Plan：大规模架构变更必须先在新会话里做 Plan-then-Do——让 AI 输出变更计划，人工确认后再执行。

0x09 总结

分析完84亿 Token、443个大型项目会话 + 14个100%成功率的小项目会话，以及七宗罪后，我得出三个真相。

• 真相一：AI 的失败 90% 是基础设施问题，不是模型不够聪明

沙箱权限、上下文窗口、重试机制——这些工程问题贡献了绝大多数失败。模型不够聪明从来不是主要原因。真正的瓶颈是：AI 不知道它在一个受限环境里。AI 不知道它的上下文快满了。AI 没有一个优雅的方式告诉你”我需要人类介入”。这是基础设施要解决的问题，不是你换个牛逼的提示词就能解决的。

• 真相二：你对 AI 的管理方式，比 AI 本身更重要

从”Reactive Micro-Manager”到”Autonomous Orchestrator”，这个进化路径里，最高效的是中间的 “Documentation-Driven Architect” 阶段。 把文档当作 AI 的外部记忆，把 Task ID 当作注意力锚点，把 Git 历史当作上下文恢复工具——这些工程实践，决定了你能用 Vibe Coding 构建多大的东西。 AgenticaSoC 的 97.4% 成功率不是靠更好的模型，是靠更好的管理。不是靠更贵的订阅，是靠更有纪律的流程。// 即便同时用了3个Cursor Ultra会员（一周一个）同样是 up-cli，结构化的高复杂度任务成功率 88.2%，无结构的低复杂度任务只有 55.0%。 结构把成功率提升了 33 个百分点。

• 真相三：Vibe Coding 存在相变——小项目的天堂是大项目的陷阱

小项目 100%。大项目无结构 55%。差距 45个百分点。crycrypto 在48小时内实现了完整的 ISO 金融密码学标准的教学工具。iamsolve 在1小时内破解了6个 wiz的 IAM 安全挑战。这些都是AI的真实能力。但当你把同样的方法用到一个多租户、多智能体、带 LeCun 世界模型的 SOC 平台时——跨越了相变临界点——55% 意味着你的大型工程会在某个关键节点崩溃。而最根本的风险不是某一次 crash，而是一致性漂移——每个 AI 会话产出局部正确的代码，但全局上你的代码库在缓慢分裂成互相矛盾的地质层。幽灵模块、沉睡的 flag、async/sync 嵌合体、8900行的回滚——这些都是漂移的症状。

好消息是：知道临界点在哪里，本身就是力量。 在临界点以下，尽情享受 Vibe Coding 的魔法。在临界点以上，老老实实切换到架构师模式——这不是退步，这是你的项目配得上的管理方式。别总想着走捷径，捷径往往是最远的路。

Vibe Coding 的终点，不是更快的代码生成，而是你成为一个用自然语言管理 AI 工程团队的架构师——一个明白”接上或删掉”、”增量不爆炸”、”结构即速度”的架构师。这是84亿 Token 和 价值约1W$的费用告诉我的，希望这笔昂贵的学费，能帮你少走弯路。

阅读原文

跳转微信打开

消耗23亿Token的复盘：为什么代码留存率仅20%？揭秘构建Agentic SOC的残酷真相

.claude
├── rules
│   ├── agents
│   │   └── agent-development.md
│   ├── backend
│   │   └── python-standards.md
│   ├── docs
│   │   └── documentation-standards.md
│   ├── frontend
│   │   └── typescript-standards.md
│   └── metabrain
│       └── metabrain-standards.md
└── settings.local.json
7 directories, 6 files

---paths:
  - "backend/**/*.py"
  - "*.py"---# Python Backend Standards

Agentic SOC
├── backend
│   ├── __pycache__
│   ├── core
│   ├── data
│   ├── features
│   ├── scripts
│   ├── tests
│   └── venv
├── docs
├── frontend
│   ├── dist
│   ├── node_modules
│   ├── public
│   ├── src
│   └── tests
├── Brain
├── nginx
└── scripts
    └── systemd
42 directories

.
├── architecture
│   ├── AGENTICA_COMPLETE_ARCHITECTURE.md
│   └── PERFORMANCE_ARCHITECTURE.md
├── development
│   ├── RESOLVED_ISSUES.md
├── examples
│   └── PENTEST_GUIDE_JUICE_SHOP.md
├── features
│   ├── agents
│   │   ├── MULTI_AGENT_SYSTEM.md
│   ├── knowledge
│   │   ├── RAG_CHAT_INTEGRATION.md
├── guides
│   └── USER_MANUAL.md
├── HEADER_STANDARDIZATION.md
├── operations
│   ├── CONFIGURATION_SUMMARY.md
│   ├── NATIVE_DEPLOYMENT.md
└── todo
    ├── ANTI_HALLUCINATION_IMPROVEMENTS.md
    ├── FEATURE_REQUESTS.md
14 directories, 56 files

阅读原文

跳转微信打开

使用AI编程做AI时代的产品经理

在Gemini3出现之后，使用AI编程的质量有了大幅提升。使用AI辅助开发产品，成本也大幅下降。以前1个sprint（2 weeks）完成的feature，现在可能1-2个下午就搞定了。但更重要的不仅仅是使用AI模型以及对应的工具，而是知道自己需要什么样的产品，以及是不是能够通过AI实现出来。纵观从GPT-3.5-turbo到Gemini-3-pro，工具依旧需要人来驾驭，尽管这个过程中所谓专家的技术护城河越来越低，不过同时也说明了作为安全工程师需要能够更好的学习使用对应工具。借此机会，把近几年使用AI编程的实践总结一下。

0x01. 整体设计：从Prompt开始

设计越详细，输出越可靠

从最初的prompt工程开始看起，其实也是随着模型一直在变化。随着模型自己能够reasoner模式并开始thinking。prompt似乎变得有些无关紧要了。但实际则是不然，个人感觉只是模型能够更好的根据你的意图去规划推理prompt中的逻辑。真要在做产品的过程中，则需要你完整的制定prompt。（除非你不知道自己的产品想要做成什么样的，而是完全依赖模型的输出，否则一定是要设计prompt的。但这里在AI编程实践中的prompt和之前博客里提到过的prompt engineering又稍有不同，这里不会关注在prompt中的“诡计”， 而是关注如何通过prompt完整描述编程过程中想要的设计（以下内容以在Cursor中进行AI编程为例）。

一般会分为几块：

• 主要的技术栈： 鉴于我python编程较为熟悉，一般会指定使用python，并且告诉Agent其使用哪些主要的lib，比如B/S架构的产品我一般会要求使用fastapi，数据库使用SQLAlchemy，密钥相关使用Cryptography, 模型相关如果涉及到Gemini会使用Google的专有库google-generativeai，其他的会使用Openai的库，以及本地会用llama_index，还有服务端用AI网关的库用于支撑多模型。这样避免AI自动帮你引用了一些可有可无的、过期的缺乏维护的、存在漏洞的library

• 目录结构和文件结构： 好的目录结构，后续在增加feature和发现bug测试的过程中极为有效，且能够更好的使用多Agent模式进行编程（意味着你拥有了多人协作的研发能力）。对于Python项目而言，一般我会需要其具备schemas目录，models目录，services目录，api目录，db目录，如果设计任务调度则会要求具备worker目录（使用worker一般会在技术栈里要求使用celery）

• 数据库： 因为技术栈里要求使用了ORM的库，其实可以忽略后端的DB类型，即便迁移，也会方便很多。在本地开发的时候，可以使用sqlite快速原型，之后同步迁移到postegre。但需要注意的是，应该在早起对数据库的schema进行定义，分别具备哪些table，哪些字段

• 业务核心逻辑：

• 服务能力： 比如以PKI服务为例，需要要求具备CA能力，Issue证书的能力（主要是把这些逻辑写进去，比如step 1: load/generaete private key, step 2 validate CSR， step3 sign the ceritficatem, step 4 return PEM data)， 以Encryption As A Service为例，会要求Receive KeyObject/ID，然后怎么decrypt，最后return nonce + ciphertext to user等。 这些其实一般会放在前面说的service目录里。

• 接口能力： 其实不论需不需要对外提供API，都应该设计API接口的业务逻辑，因为至少需要前后端分离过程中能够通过API进行通讯。这个时候，需要设计关注哪些对外暴露的接口，其API的schema需要怎么设计，例如request需要什么样的字段，response需要什么样的字段。

• 安全相关的编码： 编程语言本身的（避免常见的注入，secret相关的需要主动要求配置分离等）；业务逻辑本身的（例如要求decrypt仅发生在内存里）；基础功能相关的（用户管理，RBAC，SSO集成等）；但实际情况是，出产品原型的过程中大概率不会考虑这个板块，而是在基础功能完善之后才会增加。回到前面目录结构和文件结构的重要性就体现出来了，这个时候后续增加的模块逻辑能够很好的无缝衔接，实现出来。工程化代码一定要使具备安全能力，安全业务的产品更需要产品安全，但实际实现最初没有关注到所安全，这一点是需要反思的。

• 界面（UI）基础：其实网上有几种说法，一种是一键clone对应的页面，或者image to UI这种，但是这些基本上都是demo玩乐，真正需要自己实现产品的时候，一定需要有界面的设计。不过这里可以只设计基础的部分指定一些风格（mui, tailwindcss），具备哪些component，widget即可，真到css style（font size， color）什么的反而不必要关注，可以在后续对话中进行调整。（一定会进行调整，尤其是前端部分）

• 实现步骤： 告诉Agent从上到下如何进行实现（上面几块+这一段需要组成一个完整的prompt），例如先实现基础的DB Schema部分，然后实现核心的业务逻辑，接着提供API接口功能，最后实现看板功能。通过分步实现告诉Agent如何去工作

⚠️注意，其实也可以通过告诉模型你的需求，让其帮你设计。只需要告诉模型通过system thinking的模式（即便模型可以帮助你thinking，但还是建议你告诉模型使用system thinking你的需求，并且拆分validate，verify他的输出设计），帮你去细节化整体的设计，也是可以达到类似效果的。但是需要注意的是，这个过程则需要你关注在需求细化。所有前面的技术描述都转换为，你需要XXXX，在YYY输入的情况下，应该获得XXX的输出。最后就是review整个prompt。然后丢给Cursor编写代码。 点击此处访问Prompt示例，该prompt是Gemini 3根据设计自动生成的最初版本。

0x02. 细节调整：测试及修复Bug

必须要测试/验证 Agent写的feature, 并发现Bug进行修复。（你必须实践过才知道下文提到的bug是什么）

Cursor Agent + Gemini 3虽然能够很好的生成代码，但是对于复杂的产品和较底层的逻辑，实现起来一定是bug的。100%。这也就是为什么我在前面的博客中提倡使用TDD的方式去编写对应的代码。

这里会列出一些遇到的问题类别，以及调优和使用技巧。（以下所指均基于Cursor Agent和Gemini 3进行）

• 包管理和路径管理类问题

• 经常出现在Autorun的过程中，pip包安装失败；此类解法首先避免使用system env，为项目的project创建独立的venv，其次如果有可能应该尽量的使用uv（Use UV in cursor rules）替代pip去管理包，并编写rules告知

• 命令执行失败的问题，此类大部分是由于路径不对导致，解法可以在sanbox的autorun之外，编辑命令行。也可以主动使用绝对路径。

• 模型幻觉类问题

• 模型认为其使用了对应的内容。例如指定了模型上下文对话过程去调用工具，并根据返回的工具进行下一步预判。尽管工具调用成功，调用工具依旧会输出Simulated Report，此类问题解法可以通过加强system instructions，使其必须等待真实输出，拒绝自行模拟。同时增加工具的等待时延，要求异步任务必须在获得结果之后向模型发送。

• 模型认为其实现了对应逻辑，但实际没有： 例如CRL没有写入到证书文件，但agent一直在笃定自己实现了这个feature。 此类问题的解法是告诉Agent对应的标准（例如这里是X509），通过对规范的引用及更细节的处理过程实现具体逻辑。参考上一节业务核心服务能力部分prompt，当时需要告诉业务的具体运行逻辑。这里通过引入每个业务过程中涉及到的更底层逻辑来矫正模型的代码输出。

• 业务逻辑类bug

• 状态（Waiting Status）类的展示问题：比如有N个RAG Knowledge base，增加batch processing & index 按钮之后，documents list开始one by one的进行更新，但是总的waiting status不发生改变，在最终procssing完之后依旧是waiting状态，需要手动刷新浏览器窗口。这类问题的解法一般是： 为session id增加status字段用来刷新， 第二种方式分离API接口，例如workflow的状态展示可以使用单独的websocket接口进行更新，而非使用混在模型正常输出流里使用标签类字符

• 复杂架构类的问题，对于B/S架构出现较少。但针对B/C/S类架构比较麻烦，例如提供了B/S结构的管理功能用作服务端，同时使用Client注册到Server端提供端侧能力，并将该Client本地监听端口，作为Brower Extension的Server。由于涉及到不同类别的语言栈，模块划分等。此类问题的解法通常是： 分离作为两个项目实现，避免在一个复杂的Project里实现。B/S分离一个，Client分离一个，Brower Extension分离一个。 当然也可以设计更为详细的Prompt，指定每一部分的交互逻辑。

• DB表的刷新，部分情况下新增的业务逻辑会导致表结构的变化，但Agent不会自动解决表结构的问题（他只触发了修复业务逻辑的能力，而没有触发业务逻辑映射到DB的问题），主程序main.py自动的reload就会导致SQLAlchemy报错。针对此类问题的解法：单独启动一个agent，专门用于处理backend类的问题。你可以将类似的其他的backend类的error统统的放到该agent下面去运行即可。除此之外，再用一个Agent把所有的db类操作（init，update）代码移动到一起即可。

• 产品界面类bug：这个可太多了

• Cursor编辑器本身的bug

• 在一次输出被reject之后，并进行了revert之后。同时调整prompt删去了其中某一个需求（假设原始需求有3个，删掉一个还有2个），但在执行时，Curor有时会仍旧记忆了旧的需求（依旧是3个需求）。这个时候一般是Agent自身的ToDo列表没有更新掉，此类问题的解法：在拒绝输出的代码后，如果设计调整需求时，可以在revert的prompt那里采用直接情绪化输出。骂人即可。

• 跨服务的修改文件，这个bug比较严重。起因是在A项目里新起了个agent，prompt让其按照 http://localhost:5174 的界面调整当前界面。结果导致其夸项目修改了5174下的代码。且执行过程中，点击allow按钮允许运行代码的过程中，没有意识到已经跨项目了。还在疑惑，平常都是autorun，根本不需要去手动点击。直到发现5174界面报错，才发现原来之前的允许执行的代码已经跨项目被更改掉了。 此类问题暂时没有找到解法，只遇到了一次。只能快速的revert并修改prompt，仅让其check the ui, 不在让其follow the style.

还有一个关于界面类的bug，我并没有详细列出来。因为这种类型的bug根据业务场景的不同和交互逻辑的不同一定会重复出现很多次。例如设计的一个chat类应用，同模型进行chat的过程中，在返回结果前一般会进行waiting，但如果点击其他对话之后如果某个对话在waiting，会导致所有其他UI同步显示waiting。这种bug简直不要太多，还有点击对应agent进行对话，默认就会带入第一个agent，而不是指定界面上的agent。这类问题的解法没有统一的，首先肯定是要确定自己的业务逻辑是什么。然后进行调整即可。

关于调整，则需要先能够知道什么是widget，component，page, panel，module，box，window, sidebar等，同时能够精准的描述位置， within, under，in the left/right of , center, bottom, top,fixed, relative等，然后告诉你是想update xx style, follow xx style, move it, popup, alert it, double confirm, bring it into等等
其实就是能够精准描述对界面组件的调整。 某个element在某个位置，我想要他怎么怎么样即可。但这里其实也会出现模型幻觉类问题，我在一个产品的实现过程中。header 部分的标签宽度一直都是不符合的，且造成了其他按钮的遮盖。这个时候对话了4-6轮，模型依旧是认为设计了x个column里占了x个。哪怕情绪输出了2轮，check了所有的这个页面的代码，还是不行。最终的结局办法是进入到代码里，看对应的代码，然后手动修改的。最后固化为style rules记录下来。

针对功能调整的优化，一般来说英语做prompt很有必要的，即便你可以说模型本身会帮你进行语言转换，我也尝试了用中文在Cursor里和Gemini3对话调整UI，效果并不太好。另外就是尽量使用MAX模式而非Auto模式，需要注意的是有些模型（以Sonnet4.5为例）默认上下文空间是200K，使用MAX模式之后，虽然支持1M的空间，但超出200K的部分会快速的产生高额计费。（意味着一次对话输入可能花费1-2美金)，所以务必要详细的指定你的prompt的需求。直白直观的告诉他需要什么。

0x03. 风格迁移：学习Rules

如果我前面写的prompt和bug修复能够被理解且进行了实践，其实已经可以做出对应的产品了，此时如果你还想进一步研发具备相同风格的产品，作为一条风格鲜明的产品线，你就需要设定Cursor Rules了。

当然你也可以先dump出来，或者让Agent把你当前满意的一个产品的风格记录下来。（这也意味着可以最先原型一个最小需求的产品，用来验证其后端编程风格，前端编程风格以及其他风格的可用性，之后记录下来用于夸大产品）

让Agent输出你的前端风格

@Codebase I want to reuse the frontend style and component patterns from this project in a new project that will have a completely different backend.
Please analyze only the frontend code (UI components, CSS/Tailwind usage, animations, state management, and directory structure). Ignore all backend logic, API calls, and database schemas.
Based on this, write a .cursorrules file that defines:
1. The Visual Style: Color palette, spacing, typography, and specific Tailwind class patterns we use frequentely.
2. Component Architecture: How we name components, where we store them, and how we handle props/types.
3. Frontend Tech Stack: Explicitly list the frontend libraries we use (e.g., React, Lucide icons, Framer Motion, Shadcn UI) but mark the backend as 'flexible/agnostic'.
Output this as a single code block I can copy.

让Agent输出你的后端风格

@Codebase Act as a Senior Software Architect. I want to start a new project and I want to strictly follow the coding style, architectural patterns, and best practices established in this current backend codebase.
Please analyze my backend files (controllers, services, models, utils, config, etc.) and generate a comprehensive set of "Project Rules" (cursorrules). 
Focus on the following specific areas:
1.**Tech Stack & Libraries**: What framework, ORM, validation libraries, and tools are used?
2.**Directory Structure**: How is the logic separated? (e.g., Repository pattern, Service layer, MVC).
3.**Naming Conventions**: How are variables, functions, files, and classes named? (camelCase, snake_case, PascalCase, etc.).
4. **Typing/Syntax**: Are we using TypeScript strict mode? specific ES6+ features? Functional vs OOP style?
5. **Error Handling**: How are exceptions caught and returned to the client?
6. **Response Format**: What is the standard JSON structure for API responses?
**Output Goal:**
Produce a markdown block formatted specifically for a `.cursorrules` file. It should consist of clear, instructional "You will" or "Always" statements so that future AI generations follow this exact style.

之后将各自输出分别命名为frontend-style.mdc和backend-style.mdc，然后在新的项目里面新建一个文件夹.cursor/rules, 如果你像我之前还遇到过包管理的问题和header头无法修复的问题，可以再创建类似python-package-management.mdc和header-fix-style.mdc， 但是需要注意的是，单个rules文件也不建议内容太长。

一般我建议放置以下类别的rules：

• 后端编程风格

• 前端编程风格

• 包管理的风格（比如倾向于使用uv来管理Pyhton的包）

• 安全编程的风格

这是我的一个后端编程风格的rules

## 1. Tech Stack & Libraries
-**Framework**: FastAPI (Python 3.10+)
-**Database**: PostgreSQL
-**ORM**: SQLAlchemy 2.0+ (Declarative Mapping)
-**Validation**: Pydantic V2
-**Security**: `passlib[bcrypt]`, `python-jose` (JWT), `cryptography`
-**Task Queue**: Celery with Redis
-**AI Integration**: Google Generative AI
## 2. Directory Structure & Architecture
You will strictly follow this layered architecture:
-**`app/models/`**: SQLAlchemy database entities.
-**`app/schemas/`**: Pydantic models for Request/Response (DTOs).
-**`app/api/v1/endpoints/`**: FastAPI route handlers (Controllers).
-**`app/services/`**: Business logic layer (Functional style).
-**`app/core/`**: Configuration (`config.py`) and Security (`security.py`).
-**`app/db/`**: Database connection (`session.py`) and Base model (`base.py`).
-**`app/api/deps.py`**: Dependency injection providers (DB session, Auth).
## 3. Coding Conventions
### Naming
-**Variables & Functions**: `snake_case` (e.g., `create_user`, `get_password_hash`).
-**Classes**: `PascalCase` (e.g., `User`, `UserCreate`, `Settings`).
-**Files**: `snake_case` (e.g., `user_service.py`, `api_key.py`).
-**Constants**: `UPPER_CASE` (e.g., `ACCESS_TOKEN_EXPIRE_MINUTES`).
-**Routes**: Kebab-case in URLs (e.g., `/change-password`), but `snake_case` for function names.
### Typing & Syntax
-**Type Hints**: You will ALWAYS use Python type hints.
  - Use `str | None` instead of `Optional[str]`.
  - Use `list[str]` instead of `List[str]`.
-**SQLAlchemy**: Use the strict 2.0 declarative style with `Mapped`.
  # Correct
  name: Mapped[str] = mapped_column(String, nullable=False)
  # Incorrect
  name = Column(String, nullable=False)
  - **Sync vs Async**: 
  - Use **Synchronous** `def` for route handlers and service functions involving Database operations (unless using an async driver specifically).
  - Do NOT mix `async def` with blocking `Session` calls.
## 4. Implementation Patterns
### Models (SQLAlchemy)
- Inherit from `Base` (`app.db.base`).
- Use `__tablename__` attribute.
- Use `uuid` for primary keys:
  id: Mapped[uuid.UUID] = mapped_column(primary_key=True, default=uuid.uuid4)
  ### Schemas (Pydantic)
- Create separate schemas for **Base**, **Create**, **Update**, and **Response**.
- Enable ORM mode compatibility in Response schemas:
  class UserResponse(UserBase):
      id: UUID
      class Config:
          from_attributes = True
  ### Service Layer
- Implement business logic as **standalone functions** in `app/services/`.
- Do NOT create Service classes (e.g., `UserService`). Use functional modules.
- Pass the database session explicitly as the first argument:
  def do_something(db: Session, param: str) -> ReturnType:
  ### API Endpoints
- Use `APIRouter`.
- Inject dependencies for Database and User:
  @router.post("/", response_model=MyResponse)
  def create_item(
      item_in: ItemCreate,
      db: Session = Depends(deps.get_db),
      current_user: User = Depends(deps.get_current_active_user)
  ):
  - Keep logic in endpoints minimal; delegate complex logic to `services/`.
## 5. Error Handling
- Use `fastapi.HTTPException` for known errors.
- Raise exceptions directly in the Endpoint or Service layer when a specific logic rule fails.
  if not user:
      raise HTTPException(status_code=404, detail="User not found")
  - Use standard HTTP status codes (200 OK, 201 Created, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found).
## 6. Response Format
- Always define a `response_model` in the decorator.
- Return ORM objects or Pydantic models directly; FastAPI will handle serialization.
- Do NOT wrap responses in generic envelopes (like `{ "data": ... }`) unless specifically required by a standard. Return the resource directly.

好的编程风格其实意味着好的架构设计，新的需求特性能够快速的衔接进来，模型能够以较少的token去获得对应的解题思路。同时也能够使用多个Agent并行工作。但做产品最开始的永远不是编码，而是需求，从需求到产品之间充满了另一种设计上的思考和平衡。

0x04 闲话

无论是talk is cheap， show me the code还是code is cheap , show me the prompt， 时代在变化，工具在变化，但最终还是需要人去使用工具。从严重依赖AI进行编程的朋友那里经常听到吐槽:“以前是写代码的时间多，调Bug的时间少。现在是AI写代码的时间快，调Bug要两三天”。在概率分布的前提下，永远不可能有100%的完美实现。但得益于AI Coding能够对原型的快速实现，让人能够更关注到需求本身的交付而不需要关注背后的实现。不过这个并不适用于大型项目。自从GPT3.5 Turbo出现之后，我就尝试用用AI编程做过的一些尝试。但在Gemin-3出现以后，在编码尝试之后发现，用于大型项目不再是不可能。

限于之前Ai Studio的API Key只是Tier 1，因此充值了Cursor的20$会员，接着发现并不够用，于是改充了60$的会员，然而依旧不够用，开了50$的On-Demand，两天不到又刷掉了40$多，想了一下最终换成了200$的会员。

但是算了一下，针对设计和实现的产品来看，虽然相对价格较高。但对于研发而言，成本可谓极低。（截图内仅用了一周，实际编程可能5天的样子）

以下为部分产品的UI示例截图（最近做的终于感觉像是产品不是工具和服务了）：

最初是从4月份开始计划写AI驱动产品设计的总结，到7月份又调整了一版（把Python编程单独拎出来整理了一篇）。本来今天准备把《AI编程和产品设计实践》写完，但写到产品设计已经觉得冗长，遂决定后续重开一篇《产品设计心得》。

以下是按原目录写博客时列举的用AI做过其他的一些工具，暂列于此（时间顺序排列，但不如最近一两月感觉更像企业类型的产品，见前述图）：

• Web版本的Code Review（Python+Flask，作用是输入一段代码，能够识别漏洞及Code Review。后端接的模型是GPT-4o）

• 工作时用到的各种小工具箱 (HTML-based)

• Mac平台上的阅读Bot（基于Python，用来在阅读PDF时遇到不懂的地方直接截图，后台会进行summary & research， 后端接的是GPT-4o）

• Apple Watch的一个六爻卜卦应用（Swift语言， Cursor编辑器）

• 随机一卦（一个基于web的类似万剑飞行特效的，这种css完全不会，全靠AI，但是由于事后没有学习这个AI写的CSS代码，所以显得也很傻瓜）

• CISSP考试工具（纯前端应用，JS+React，使用了Claude2.7，Gemini2.5分别做过不同的版本）

• AI Browser (Nodejs+Electron, 最初设想是浏览器驾驶窗，AI实时的接收浏览器的上下文，并给出分析)

• Vault平台（Pyhton+Flask, Java+Javalin. 一个支持EAAS，多CA集成，证书管理和机构证书管理签发的平台，PS:AI可以把300人天变成30人天）

• 回测平台(Python+streamlit, 实现了一个常见策略回测的可视化小工具)

除此之外一些Web的样式的调整（例如博客，书单网站等），类似SRC的Security Center宣传页面等，以及还有一些原型的设计：

• Solution Craft（希望通过一个平台实现企业在管理整个产品研发流程时能够involve到不同的部门进行资源管理，并能默认嵌入SDLC以及DevSecOps，支持多种框架的mapping）

• 神灯阿拉丁（一个关注留守儿童心理健康的平台）

阅读原文

跳转微信打开

即见树木，也见树林。

试着从架构师视角拆解一下日常运营中需要知识，以求即见树木，也见树林。

0x01 基础知识

日常运营中最常见的无非是DER，CER，PEM格式的证书及私钥。这些文件的背后到底是如何编码定义的？实际都是通过ASN.1编码规则根据一定的数据结构定义完成的。于此同时，真随机数带来的不可预测性决定了密钥的安全性。

1. 格式与编码

ASN.1定义了一系列的编码规则，能够把证书的数据结构（X.509格式定义了证书的数据结构）转换为二进制进行存储。同时根据不同的应用场景，又存在不同的证书封装格式。在不同的标准间进行转换。

// 关于X系列标准，感兴趣的可以扩展去了解一下ITU-T， IETF，ISO，IEEE之间的协作模式。看一下整体怎么做出来的，为什么有ASN, RFC, ISO标准等。他们如何负责不同领域的标准制定，以及对外进行推行。例如关于PQC的最新标准是Y.3830

1. 从随机数开始到椭圆曲线

先看随机数的生成，一般有HRPNG和CSRPNG。HSM具备HRPNG模块，提供生成真随机数的能力。真随机数是密钥体系的基础，不可预测的真随机数用来做密钥，iv，Nonce等都可以。除了HSM之外，日常硬件也提供CSRPNG能力，一般是读取各种电子噪声做为熵池，然后通过计算得出随机数。不过这些都是硬件层面和Kernel层面。在系统层面，操作系统封装了对应的接口，用来生成随机数。之后又可以通过编程语言完实现调用，并达到跨平台的作用。常见的SDK有openssl（c/c++, 同时提供了多语言的binding），tink（java系），bouncy castle（java系），cryptography.io(python系)，这些SDK封装了常见密码学的算法实现，用以支持对应的mechansim，同时支持一定的密码学套件（ciphersuite）。有的SDK甚至提供多Provider并且具备一定的Key Management功能。

不过最根本的还是数学原理，曲线方程，求余，有限域等等。

因为之前的博客里总结过常见的算法（参考浅谈加密基础设施，但是缺少了椭圆曲线这一块，因此特意整理了一张Slide在这里。

RSA是基于大数分解难题，而椭圆曲线则是基于椭圆曲线离散对数。这里选择的是以p256曲线为示例，通过查看对应的曲线参数并通过matplot绘制了对应的图像。但实际并无法完全可视化出来。具体生成过程和曲线要点就不介绍了。直接看图。另外就是需要着重关注的ECDH和ECDSA。也是看图吧。公式没什么可讲的。点乘且符合交换律的情况下使得S=S‘， 也因此实现了在仅知晓对方公钥的情况下完成对应的秘密交换能力。后续该S通过派生函数作为对称密钥完成后续的加密。 值得一提的是，安全的曲线生成的公钥Q一定仍在曲线之上。如果不在则是一条坏曲线，且可能存在风险。不过这些运营过程知晓即可，实际密码学库选用公开可靠的即可。类似的在ECDSA中，如果随机数K是固定的话，也是一种漏洞。可以搜索下sony ps的案例。

0x02. Applied Cryptography运营须知

ECDH算法虽然能解决交换的问题，但解决不了运营过程两侧安全不对等的问题。真随机数带来的安全性也无法解决明文传输过程的泄漏。算法安全，实现的库不一定，调用起来也不一定，人的运营更无法琢磨。

实际的运营过程，最近两年也见到了传统金融机构里太多的草台班子做法。妥妥的Micky Mouse Operation（MMO）。让我们来看一下：

• o 不要设计自己的加密算法，同理也不要自己实现对应的加密算法库。
  MMO： 见过一些研发团队自己设计AK/SK的，所谓的AK/SK里再截取后面x个字符串作为加密算法。

• 密钥和数据的价值一致

• o 不要使用固定的IV
  MMO：我们在技术文档规范里约定好固定的IV，这样每家接入机构用一样的就行了。使用不固定的IV还要增加研发成本。

• o 不要长时间使用同一个密钥，密钥需要具备生命周期
  MMO：有什么强制规定要求要更换吗？能不能不换？能不能申请延期？密钥更换，那是影响业务的！

• o 不要使用同一个密钥用在不同的业务场景里，类似的不要使用同一个随机数在两个用途上。以及使用证书也应该区分对应的业务场景。验证签名的证书和加密数据的证书等。
  MMO： 还要使用两个密钥好麻烦，一个就行了吧！

• o 不要密钥套密钥，在非混合加密体系之外，不用对称密钥保护对称密钥然后多套几环
  MMO：A密钥明文保护B密钥，B密钥被C工具里的密钥保护，C工具里的密钥被HSM的LMK保护。

• o 不要在明文上计算MAC，在密文上计算MAC
  MMO：哪有什么区别，怎么方便怎么来。我就要先计算明文，再计算MAC

• o 不要明文存储私钥，更不要明文存储私钥的密码。
  MMO：压缩包加密一下传输不就行了！密码？密码放在配置文件里就可以了啊。

• o 不要存储私钥在本地，应该放到专属的KMS里
  MMO：本地建个文件夹，设置一下访问权限不就行了。

• o 不要明文存储私钥的分量
  MMO：不仅拿到了明文分量，还要合并起来问下，你打印的是这个明文分量吗？（内心OS：我特么怎么知道是不是这个明文分量）

• o 不要使用弱曲线，弱算法，弱CipherSuite
  MMO： 什么是CipherSuite， GCM我们不支持啊！为什么要升级，3DES就用着挺好的啊，为什么要用AES。有什么规定不能用吗？

• o 不要忽略证书中的CRL校验
  MMO：我校验个嘚，不仅不校验CRL，我连证书本身的有效期都不校验。我有专线！

• o 不要只检测签发的CA，还要检测签发的对象。

• o 避免使用Self Signed证书，以及签发多年期证书
  MMO：能签发个5年期的TLS证书吗？ 为什么测试环境不用测试证书（测试CA签发的证书）？生产环境用生产证书？（内心OS：合着测试生产是靠CA的测试生产区分的？）

• o 避免使用通配符证书
  MMO：我一张证书走天下，方便使用，又好管理。还能降本增效，人见人夸。

其他运营场景问题：

• 密钥使用LMK保护还是KEK保护？如何选择？

• 如何应用Keyblocker格式以及KBPK？设置Keyblocker字段的取值？

• 交易网络中PIN Key和Mac key的重置应该如何进行？

• 是否需要设置专门的密钥接收人员？保管人员？

• 哪些情况下应用可以直接访问HSM？

• CFCA的SDK申请证书生成时不具备私钥保护口令怎么办？

• 根CA是否需要离线？“HA”在密钥场景里的实现是什么样的？

• HSM只支持白名单访问的情况下，如何设计使用？

• HSM不提供SDK，仅支持TCP/IP访问发送指令报文的情况下，设计EAAS服务使用哪种设计模式比较好？

• GCM的正确使用姿势是什么？需不需要设置附加字段？尤其是针对支付过程中的交易信息的加密？如何用好附加字段。

• 是否需要为CDN和主站签发两张证书？（同一个域名，两张证书）

• 是否需要设置双证书，用来实现HA？

• SAAS服务是否需要自定义到企业内部域名，并由内部负责签发证书？

• 【国产专题】使用CFCA双证机制，机构A支持，但机构B不支持怎么办？HSM不支持双证CSR接口怎么办？

• 【国产专题】没有CFCA的CSP时应该怎么下载证书？

• 【国产专题】CFCA返回的双证书和加密的私钥格式如何处理？

0x03 总结

这篇文章花了十天的时间准备（10/09-10/19）,其中主要是在绘制上面几张图。 翻了翻我的TODO记录时，发现除此之外还有一些想去记录，但没有写下来：

• 完整性校验有哪些不同的MAC算法

• Keyblocker（TR-31）的应用场景及使用？

很多东西，一旦松懈就不可能再记录下来了，于此同时也看到了草稿里一篇7月底关于AI如何设计产品的文章，翻了几次，都没有写完。写的也不甚满意。

回到这篇关于运营的文章，这两年也算是对接了国内四十多家银行、发卡、收单机构。只有一两家，也许四五家是看起来正常一些的。传统金融真是容易混日子的地方，不专心业务和技术，那就只能专注其他的细节。我最多听到的就是：“我之前怎么没见过？这个对吗？”。扯淡的对接里做扯淡的解答只会变得更加的扯淡。Micky Mouse Operation和所谓的金融安全真的是格格不入。

最后，最近一直想着去提倡Less Operation， More Efficiency，以及另外一个概念，Architecture As Code, Architecture for Compliance. 这可能是作为架构师后第一次独立提出的概念了？我疑惑着翻看了之前记录的对于SDLC，安全左移，纵深防御理解的文章，翻了翻对入侵检测领域实践，密钥实践，数据安全实践，网络和云安全实践的总结。不知道企业安全的突破点在哪里，按理说不应该这么快产生倦怠，还是看多了Micky Mouse Operation让我变得疑惑了？（音乐起： 《没出息》，本来应该是从从容容游刃有余，现在是匆匆忙忙连滚带爬。 //形容现在JV企业，真是真他妈太形象了。）

参考资料

• 力荐！大佬文章： A Few Thoughts on Cryptographic Engineering

• A Warm Welcome To ASN1 And Der

• ITU-T Standards Recommendations

• ASN.1 Made Simple — What is ASN.1?

• SM2 Curve

• Standard curve database

• 国密算法OID

• Object Identifier (OID) Repository

• 浅谈加密基础设施

• 浅谈隐私计算和数据安全

• 数学公式可视化工具

• Safe Curves

• OpenSSL Architecture

• Web Crypto API to Get Randoms

• Dual_EC_DRBG

• The Many Flaws of Dual_EC_DRBG

阅读原文

跳转微信打开

再也不说一次打包，到处部署了。

1. Design

收集需求，拆分需求，保留预算，编写需求说明书（BRD），制作HLS，同时绘制了一套UI（使用Figma）。但是因为种种原因，预算失效。只能自己下场编写。

因为需要自己编写，所以需要重新设计研发里的技术架构，我这里选型是以python技术栈，采用flask提供web服务。通过celery提供异步调度的任务。但由于CFCA平台只有Java SDK，所以需要重新wrap业务流程为API服务。同时，需要从flask调用该API Services。链接数据库采用ORM框架，便于测试和迁移。测试开发时选择Sqlite，生产部署时选择Postgres。

前端的结构拆分并没有画，主要包含User Panel， Key Management Panel， Certificates Management Panel，Crypto Box Panel，Financial Panel等，每个Panel里面是list of key/certificate, 之后顶部为search box。点进每个list的item里，可以进入详情页，管理操作等。

2. Build Infra

因为公司内的资源申请流程复杂，也不能使用AI，同时我这个平台的设计不涉及到公司内部平台的数据。于是自掏腰包，通过Google云来搭建一套基础设施。出于编码需求，直接选择了Code Server作为IDE，便于随时随地编辑。之所以选择GCP是因为之前都是用AWS和Azure、Aliyun，而且早年用GCP体验不好，导致放弃了。最近重新捡起来对GCP的学习，因此也把这一套搭建在了GCP上。

• Code-Server Host On GCP Compute Engine

• Casdoor on Docker

• Nginx on VM

// 中间还用Cloud Run和Cloud Build搭建了一个微服务应用。值得一提的是在GCP在设计上给用户的安全感是要强于其他云的。这也印正了早年被面试时问到的一个问题，如何让用户觉得你的产品是安全的，只有在GCP上体验到了。无论是创建Compute Engine时，还是解析绑定DNS给Cloud Run用时，都有一种感觉，平台在帮你做一些默认安全的事情。这一点值得称赞。

其他需要使用到的工具

• Cloudflare (DNS Management & CDN)

• Gemini Chat / Gemini Code Assistant / Gemini Studio API Key

注意： 这里有个问题就是Code Server不支持多用户。

3. Development & Testing

从方法论上推荐TDD，测试驱动开发，这样确保一个小的单元内的代码没有太多错误。具体怎么实现就不多赘述，参考之前总结的软件工程实践：以Python为例， 尤其是AI编程下的部分。

不过这里还是会提一下关于配置分离方面的实现。（其实是因为踩了一些坑）

关于配置分离

文件目录结构

├── cfca│   ├── Dockerfile│   ├── libs│   │   ├── CommonVO-3.3.9.1.jar│   │   ├── RAToolkit-3.3.9.1.jar│   │   ├── SADK-3.7.2.0.jar│   │   └── slf4j-api-1.7.36.jar│   ├── pom.xml│   ├── src│   │   ├── main│   │   │   ├── java│   │   │   │   └── com│   │   │   │       └── legendary│   │   │   │           └── javalin│   │   │   │               ├── ApiServer.java│   │   │   └── resources│   │   │       ├── xxx.jks│   │   └── test│   │       └── java│   │           └── com│   │               └── legendary│   │                   └── javalin│   │                       ├── Test3101.java│   ├── start.sh│   └── target├── docker-compose.prod.yml├── docker-compose.dev.yml├── start.sh├── stop.sh└── web    ├── Dockerfile    ├── app.py    ├── config.py    ├── initdb.py    ├── requirements.txt    ├── settings.dev.yaml    ├── settings.prod.yaml    ├── tasks.py    └── templates        └── index.html

通过start.sh传参的形式，实现生产环境或配置环境的服务启动，例如 ./start.sh dev 或 ./start.sh prod, 命令执行后会分别会去读取对应的文件，例如docker-compose.prod.yml或docker-compose.dev.yml 。以下为start.sh内容和docker-compose.yaml文件

#!/bin/bashENV=${1:-dev}ENV_FILE="docker-compose.${ENV}.yml"if [ ! -f "$ENV_FILE" ]; thenecho"Error: Environment file '$ENV_FILE' not found for environment '$ENV'."echo"Usage: $0 [dev|prod|...]"exit 1fiecho"Starting services using environment: $ENV ($ENV_FILE)"docker compose -f  "$ENV_FILE" downdocker compose -f   "$ENV_FILE" builddocker compose -f  "$ENV_FILE" up -decho"Waiting for service up"sleep 30# Run the database initialization scriptecho"Initializing database..."docker exec web_app python /app/initdb.pyecho"Database initialization complete."

之后根据docker compose文件去加载对应的参数

services:postgres:image:postgres:12-alpinecontainer_name:postgres_dbenvironment:POSTGRES_USER:XXXXXPOSTGRES_PASSWORD:XXXXXXPOSTGRES_DB:XXXXXvolumes:-postgres_data:/var/lib/postgresql/data/networks:-app-networkredis-broker:image:redis:alpinecontainer_name:redis_brokernetworks:-app-networkcfca-api:build:context:./cfcadockerfile:Dockerfilecontainer_name:XXXXXrestart:unless-stoppednetworks:-app-networkweb:build:./webcontainer_name:web_appports:-"127.0.0.1:5000:5000"volumes:-./web:/appdepends_on:-postgres-redis-brokerenvironment:-CRYPTO_ENV=prodnetworks:-app-networkworker:build:./webcontainer_name:celery_workercommand:celery-Atasks.celery_appworker--loglevel=infovolumes:-./web:/appdepends_on:-postgres-redis-brokerenvironment:-CRYPTO_ENV=prodnetworks:-app-networknetworks:app-network:driver:bridgevolumes:postgres_data:

然后config.py 会根据 crypto_env去加载对应的settings文件, 例如settings.prod.yml或者setting.dev.yml

# settings.dev.ymldebug:trueflask_env:"dev"secret_key:"xxxxx"# Database Configurationsqlalchemy_database_uri:"sqlite:///cryptovault.db"sqlalchemy_track_modifications:true# CORS Configurationcors_resources:"/api/*":origins:"*"# Celery Configurationcelery_broker_url:"redis://redis-broker:6379/0"celery_result_backend:"redis://redis-broker:6379/0"celery_timezone:"UTC"# Development CFCA endpointscfca_api:base_url:"xxxxx"certificate_apply:"xxxxx"certificate_download:"xxxxx"timeout:20# Certificate Authority Configurationca_api:base_url:"xxxxx"key_id:"xxxxx"auth_key:"xxxxx"# Email settingssmtp:server:"xxxxx"port:587username:"xxxxx"password:"xxxxx"from_email:"axxxxx"use_tls:true# Development SSO settingscasdoor:client_id:"xxxxxx"client_secret:"xxxxx"discovery_url:"xxxxx"# Login Configurationlogin:view:"login"

# -*- coding: utf-8 -*-# config.pyfrom dynaconf import Dynaconfimport osenv = os.getenv("CRYPTO_ENV", "dev")env_files = ["settings.yaml",  # Load default settings firstf"settings.{env}.yaml"# Then load environment specific settings]settings = Dynaconf(    envvar_prefix="CRYPTO",  # export CRYPTO_FOO=bar    settings_files=env_files,  # Load these files in order    environments=False,  # We're using separate files instead    load_dotenv=True,  # Load .env file    encoding="utf-8",    merge_enabled=True,  # Enable merging of configs)print(f"Loaded environment: {env}")print(f"SECRET_KEY: {getattr(settings, 'SECRET_KEY', None)}")

最后在app.py里面调用config.py导入配置。

from config import settings# --- App & Database Configuration ---app = Flask(__name__)# Load configuration from Dynaconfapp.config.update({'SECRET_KEY': settings.SECRET_KEY,'SQLALCHEMY_DATABASE_URI': settings.SQLALCHEMY_DATABASE_URI,'SQLALCHEMY_TRACK_MODIFICATIONS': settings.SQLALCHEMY_TRACK_MODIFICATIONS,'DEBUG': settings.DEBUG,#   ........})

另外值得一提的是，最开始采用了单文件存两份环境的变量，但导致了环境变量覆盖（不过更可能是没有设计好）。还有一点就是因为Sqlite是文件型数据库，Celery和Flask都会读写该数据库，但由于Celery和Flask是运行的两个容器，通过共享Volume挂载的形式读取到的Sqlite的文件，导致出现了锁的问题，而由于没处理好锁的话，便会一直出现报错。

4. Deployment

部署实际是我与工单不得不说的故事，当然这不是意味着设计的流程和工单非常严谨。而是说明了在金融企业里，大家习惯了沉闷，把慢的离谱的手动的流程都当作是一种可以接受的合理的合规的存在。另外就是因为快速迭代并不是这里的优先级，稳定才是。所以更加导致了流程和制度的层层加码。即便应该使用更好的方法去实现控制。就像之前提到过的实现安全的纵深防御，但不是重复防御一样的道理。这么多工单，真的是有必要的吗？

工单举例（仅我能想起来的，中间有的要开几遍）：

• VM的申请

• 堡垒机的访问权限申请

• 特权账户的申请

• 防火墙的开通（我的IP向平台开通访问；向办公网开通访问；平台允许我的IP等）

• 防火墙的例外申请及记录

• 服务邮箱的申请

• 申请域名

• 申请DNS解析

• 申请企业CA签发的证书

还不包含以下等等

• 代码的扫描

• 容器的扫描

• 托管密钥的申请

• 内部SSO的集成

• SIEM的集成

看到这里，我在想如果我是一个研发，可能我也要骂DevSecOps。如果不是经历了一遍研发设计和部署，那么这些安全控制的东西可能还会令人沾沾自喜。但实际看下来，则是非常影响研发效率的。但快速迭代和安全之间一定是要取得一个平衡的，如何实现，值得思考。

5. Issues

这里记录一下，从研发之初到部署时遇到的过的Bug，以及如何解决的。

工具或平台（Platform）类：

• A平台页面触发的申请动作会触发平台侧邮箱通知，但api申请则不触发。那只能自己实现邮箱通知的功能

• A平台测试环境IP:PORT使用443， URL使用9443，但却仅告知了开防火墙443，排错时才发现9443也存在通讯。但在迁移到生产时，直接更换了URL中的IP之后，又发现生产只访问URL且使用443端口

• A平台测试环境的登陆证书下载后，平台侧未同步，导致访问失败

• A平台生产环境登陆证书转JKS格式后未添加OCA1的证书链接导致NO Trust Store

• B平台的API文档里的传参和实际传参不一致。 报错信息几乎为0。 {K:[V]} 不是 {K:V}， 有的传string of list但不是传string。换了最新版的文档就解决了

关于Docker/Podman：

• 即便号称Podman和Docker兼容，且默认Rocky上是安装的Podman，但Docker Save的Image在Podman Load之后无法完全正常运行。（需要深入了解才行）

• 【开发时】Windows平台中Dockerfailed to solve: failed to read dockerfile: open /var/lib/docker/tmp/buildkit-mount770356576/Dockerfile: no such file or directory， 采用 cd "C:\Program Files\Docker\Docker" && ./DockerCli.exe -SwitchLinuxEngine的形式进行修复

• 【开发时】打包java为镜像后，运行时显示无法找到main class。原来是因为COPY --from=builder /app/target/*.jar /app/application.jar，实际需要copy一个指定的jar即可，指定jar拷贝进去即可生效。即便target下面只有一个jar包。

• 【开发时】Compute Engine的Disk空间不足。docker system prune -a -f && docker volume prune -f可以释放部分空间，但是不如挂载新的盘。

• 【开发时】无法保存CASDoor的配置，因为Disk Space不足

• 【开发时】使用docker-compose文件打包时，本地镜像缺失但无法拉取，已经docker login过。后直接单独拉取镜像后，docker compose build则正常。

OS的版本，测试时用的Ubuntu， 部署时用的Rocky。另外现在用docker compose不用docker-compose了。另外部署时(Rocky8 Linux)遇到的dockers问题，开发时(Ubuntu Linux)一次也没遇到过。

• 【部署时】rocky 默认使用podman，需要单独配置镜像才能安装docker-ce

• 【部署时】docker load/save 和 import/export不一致。需要保证全layer。 podman不支持import

• 【部署时】ubuntu上的docker compose起来的postgresql直接可以用，rocky上 的docker compose起不来postgresql

• 【部署时】使用network可以内部链接，但通过服务名无法寻址。

• 【部署时】Nginx反代无法访问到docker暴露的本地端口，需要指定容器IP。可能是firewalld导致的

• 【部署时】使用暴露端口到本地时，应用内无法访问127.0.0.1:port

• 【部署时】容器起不来直接崩溃退出，默认ENTRYPOINT是执行java程序，可以传参给entrypoint给docker以便进入容器排错。docker run --entrypoint /bin/bash cfca-api

• 【部署时】Docker的Service不能靠Service Name寻找到，增加Docker Network配置即可。在docker-compose文件中全部设为同一个network

• 【部署时】起容器时load本地的文件，但权限不对，无法打开。

• 【部署时】申请的公司内部的smtp邮箱登录是按照域账号，不是邮箱账户作为用户名。

• 【部署时】设计了nginx作为reverse proxy，但SSO的callback里填的是http，导致nginx完成SSO认证之后（https）跳回了http，访问失败。解决方案就是将nginx http都重定向为https。当然，更应该在SSO的callback的里填写https的链接。同样的还有一个安全问题，就是把127.0.0.1的测试用的callback去掉。

• 【部署时】docker compose文件正常能够启动postgres，但是rocky上起来之后，显示缺乏pg_hba.conf文件，增加之后，重新启动则显示password authentication失败，进入容器排查，发现无对应用户。创建无法实现，通过init.sql在创建时也不生效。最后单独启动postgre并传入命令行参数可以生效。具体原因未知。

Windows：

• celery在windows平台和linux平台下运行的不一致，参数不同要加-P evenlet，否则终端会假死。celery -A tasks.celery_app worker -l info -P eventlet 因为默认实现的prefork不兼容，fork()函数的系统调用是在linux下的。 但同时要注意， celery的beat功能不支持-P eventlet

• 使用pipreqs生成依赖时显示编码问题，强制使用utf-8解决，pipreqs . --force --encoding utf-8

编码（Coding/Programing）类：

• application读jks文件路径不对，测试时和打包后不一致。

• print到stdout但是不显示，更换使用logging模块显示

• celery 调度任务失败了，但是状态被记录了。即便后续重启任务，状态不会被刷新。（不知道为啥）

人为疏忽类：

• 单词拼写错误，xxxxservice vs xxxxservices ； orgnization vs organization

• 两侧都要开防火墙： 机房出网要开防火墙，访问对方端点要加机房的出口IP。 然后防火墙说开通了，实际测试不通。因为还有一条deny all的策略。

• 配置分离后，填入了平台正确的生产环境Token，结果显示未认证。检查发现，平台侧创建后未启用该Token

AI类：

• 删除了不该删除的代码，逻辑改变，疯狂报错

• 增加了不该增加的特性，页面逻辑改变

• 为Docker Compose file优化时增加了Health Check，然后该服务本身没提供healthcheck端点，且之后有服务依赖该容器起来，导致接连启动失败。

6. Conclusion

先看AI，在整个研发过程（业余耗时2月）中。AI体现出了无比高效率的编码和排错思路，尤其在前端代码的编写上。让人非常舒服的同时也暴露了一个问题，那就是只会对AI提问但不会动脑的话自己也会降智。

再看部署，对Docker的一处build处处运行过于自信。以至于预估的一天内部署完成，实际花了3天左右的时间。

再回到安全，从研发而言来看DevSecOps对技术的成熟度和研发人员素质的要求确实有点高了。企业里连devops的人员能力都没有，还谈DevSecOps，痴人说梦。

最后不得不说，最不安全的就是做安全的，一点不假了。

最后的最后，一些技能真的是时间久了不用就忘。所以熟能生巧又何尝不是一种本领。

阅读原文

跳转微信打开

安全架构师是团队的鸡肋吗？

这篇博客最开始计划标题为《你需要一个安全架构师吗？》一会儿又想改成《安全架构设计中平衡的艺术》，最后又想叫《安全架构师的吐槽大会》

安全架构师的工作是干吗？

首先，问自己一个问题，安全架构师的工作内容只是做架构设计吗？从工程的纬度来看，要求一个安全架构师上能够要写Policy（资深点的可能还需要制定Strategy），分析需求，确定Scope，拆解Gap，制定解决方案等；中能够做实施，选型POC，部署运维，上架交付；下能够做运营，告警分析，流程编写（SOP），知识培训，应急响应，事件复盘等；这意味着一个架构师能够随时的快速补位到任意一个角色。从团队和项目纬度来看，一个合格的架构师应该能够快速的Lead一个项目从开始到结束，能够完成跨团队的沟通，站在方案视角下协调各方的利益，使Stakeholder能够接受方案并能够推进方案的顺利进行。还要能够跟进方案。从治理的纬度来看，应该能够理解监管合规的条文约束对应在技术上的语言转换，换句话说要知道的是合谁的规矩？受谁的监管？代价多大，又能够干些什么，尺度在哪里，灰度在哪里？怎么样转换官话要求到企业内，怎么把框架/模型、新技术跟现有技术栈结合，怎么从流程策略补全？是否需要引入新的产品，能不能实现一个Quick Win等等。

当然这都是理想情况，实际情况，架构师只是极小的一部分。在其中某个领域担任相应的角色。甚至可能做着一些完全不搭边的事情。

安全架构师需要专业吗？

我的回答是，Yes！不仅需要在技术上专业，还应该在职场上。不论是你在项目中承担POC的角色，还是换了个名字叫Business Partner。都务必应该扮演好这个Role所需要做的事情。我不是一个绝对的流程主义者，但我一定坚持那些必须的节点。当很多时候大家都在说技术不是问题，只怕是已经遇到了很多的技术问题。但相信有很多人更加聪明，因为公司又不是我的，我又何必认真？大不了离开之后，管我屁事？无意讨论好坏，立场不同，结论自然不同。回答是否需要架构师专业的话题上，我先列几个问题以供思考：

• 如何从业务需求思考和评估未来的架构设计需求？

• 如何避免降本增效还是降本增笑？平替的过程中，哪些可以用开源的，还是都可以用开源的？

• 我在做纵深防御还是重复防御？ //掩耳盗铃竟是我自己

• 技术设计的平衡边界在哪里？

• 制定的目标和指标具备可落地性吗？如何衡量？

当然技术的专业性之外，职场中团队的管理也非常重要，如果管理不能行之有效，那所有的技术方案和所谓合作都是白搭。换一百个名词也没有用，从POC到BP（Business Partner）只是换汤不换药罢了。有时候一个正常的方案正在顺利推进（可能是我自以为是的错觉），遇到一些奇怪的同事之后，事情就变得复杂了。急转直下，成为一坨DB。

我同时也整理了一些案例，可以用来看技术纬度是否需要专业(当你见识了所有混乱的组合，也许才能体会我对专业的认可）：

• 金融企业总是因各种原因会拒绝数据上云，因此产生了一些所谓的“存算分离”的模式？那么这个边界在哪里？一眼看起来是用在哪里解密作为了一种边界？那继续来看，怎么判断这种边界？以及是否可以通过内存转储来判断内存是否安全？是否要求Vendor在云环境下除了客户数据在IDC之外，还需要提供关于密钥安全的一些说明？那是不是又可以引入TPM了,以及是使用二级密钥三级密钥结构？与此是不是需要密钥分量? 密钥的分发和校验要不要引入keyblock,填充模式的要求呢？ gcm. cbc.业务不支持的情况下呢？

• 金融企业还会尽可能避免PII信息出现在不该出现的地方？比如说日志中，那么解决方案是从通过公共SDK库升级实现Log的统一脱敏？还是统一处理所有吐日志的中间件，把所有消息队列经过规则引擎过滤一遍？还是检查所有的代码，正则一下打包发个新版本？

• 厂商最近都喜欢做ALLINONE,你做我也做，那么问题来了,卖点看着不错，但我该怎么用？类似XDR可以推基线，UEM呢？这里出现了一个问题，功能重叠部分，怎么设置只在一处开关，整体怎么设计？你Proxy要流量解密，我DLP要解密流量，他SASE也要解密流量？不好意思的是，有时候你又用了M365系列做生态（先抛却国内国外版本差异的巨坑）, 产品如何集成三方的产品？某个地方你支持Conditional Access想弹二步验证，那我entra呢？这个产品要黑名单，那个也要，一堆产品一起怎么运行起来？

• 上云和SAAS也是一个选型的趋势，如果我的Vendor都只提供Saas产品，我除了通过合同约束，采购准入，三方认证之外，又能提供哪些控制措施？

在这些场景里，不仅是通过技术对问题的识别和提出解决方案，也很考验自己是否能够具备心力维持是否退一步。相信大家心中，一定会闪过一句：“又不是不能用！” ， 但千万不要还没有踏出第一步，就已经放弃了。有时候你知道不是自己能够决定的，但也不应该在一开始就缴械。

我讨厌不够专业，因此也时常怀疑自己。如果是环境问题，不要内耗，问题不在你。在你现在所在的位置上，尽责尽职就够了。有时候我听到一些车轱辘话也觉得想笑。例如:功能肯定可以实现,但是可能会影响性能。但是要知道，这些是不能认真的，如果你真的认真去问什么时候能实现，大概相比原版本增加多少性能损耗？这时候你就是杠精，不识趣的杠精！和你的语气，态度没有关系，和你的出发点也没有关系。

你的团队需要一个安全架构师吗？

这个角色似乎能帮你变得更好，但却没办法阻止变得更差。

这个问题其实我无法回答，需要老板们才能回答。很小的企业里可能不存在安全架构师，也不会单独去招安全架构师。一个安全工程师就可以充当安全运营，安全运维。在这个过程中也不要想有什么完善的制度/策略。能简单的建立起SOP已经是难如登天了，与此同时，公司能存活下去也就不错了。也别想什么预算，除了不得不买的东西基本都是开源产品。文档的沉淀也是看命。对于ToB类的企业，除了出于售卖目的请三方拿些等保的证书，基本上应该是什么也没有了。这种情况随着团队的规模增长到3-5人，意味着企业已经从开始关注安全到开始付出，但实际也不会有什么能改变现状的能力，只不过几个人之间互相交叉的看着运维运营的产品，看看攻击处理处理告警，买到的也只是管理者的部分内心安慰。等到了5-10人，似乎开始关注到了合规的部分，这时候会为等保，ISO27001投入精力，设置专职岗位。然而专业的合规项目背后，往往不需要专门的合规团队。一个专业的项目经理就能实现，收集到对应的资料即可。当然，任何专业的人都是很难找到的。一个专业的具有安全项目经验背景的项目经理也是大海捞针。使用开源的产品尚且要求你自己有运营部署的能力，进行自研虽然不见得比商业采购更加节省成本，但却能够更满足企业内部的定制需求。那纯粹的供应商外包管理，又能做的了什么？外企里很多都是一个中介配个供应商服务结束。我以前以为工程师要熟练的掌握对应的产品，结果在一家Director比工程师还要多的公司里见到了Proxy模式如何运转的，有时候觉得找几个链家的员工不也能干的下去。起码链家员工还能对自己的Scope有一个明确的认知，知道什么是边界感。当然，当团队中存在这种“人物”， 实际不再需要安全架构师，因为谁来了也救不了。

那么问题来了，当你觉得运营水平低下？当你觉得产品没有效果？投入很多钱买了一堆废品？是当你觉得招了不少人却发现工单压的喘不过气？还是当你以为买了先进的产品却告警应急频频？也许给了1kw的预算说多不多，说少不少，但为什么安全水位还在持续在下降？从预算节省，运营增效，架构远景的方向是会需要一个安全架构师吗？我的内心是认为极度需要一个具备Leadership的专业架构师来进行大刀阔斧的改变。但我不是老板，所以我无法回答这个问题。

回头看看，安全架构师工作存在很强的壁垒么？似乎也没有，喂给AI充分的场景之后，似乎没有什么不能解决的。尤其是在没有人追求质量的时候，为什么不用AI的呢？ 而且人类的幻想似乎也不比AI轻多少，例如对厂商的偏见，对未知的恐惧，等等。有时候，我觉得自己其实不用存在目前的团队里，因为这对降本增效没有任何帮助。Less Operation， More Efficient？这动了太大一块蛋糕。Defense In Depth？什么我的DID只是重复没有深度！Zero Trust？怎么可能，我都快要用三套MFA了，谁会信任我。

我没事的时候就刷LinkedIn，去看人家的Principal Security Architect和CISO的成长路线。我以为我在窗口看世界，却忘了萤火之光无法长久。曾几何时，普通的技术实践也成了井底的天空，既然没见过，那又怎么可能是真的？我身边的每个人看起来都很聪明，履历也很光鲜。只有我不那么聪明。

既食之无味，弃之……则不可惜。

阅读原文

跳转微信打开

根据2025年06月05日考试及之前备考笔记整理的CISSP备考指南

阅读原文

跳转微信打开

简单记录一下清算网络（卡组）相关的技术及安全

0x00 引言

清算网络作为支付业务中的重要一环，承担着转接和清算两项主要的功能。目前全球比较有名的清算组织包括Visa(维萨)，Mastercard（万事达）,American Express(美国运通，以下简称AMEX),Discover（大莱），银联（UnionPay）。 国内的清算交易组织，还包含网联（NUCC），其中银联主要负责银行卡支付相关，网联主要负责非银支付，出于对三方支付监管的需求而成立，并逐渐通过清算网络完成了收单侧断直连和发卡侧的断直连。如果从系统维度，还应包含城银清算支付系统，农信银支付清算系统等。

AMEX和MasterCard分别于2019年和2023年在国内获得《银行卡清算业务许可证》。其中AMEX和连连数科共同出资并和银联进行合作，而MasterCard则是和网联进行合作。通过该方式使国外卡组能够在国内得以开展业务。这类公司，业内也称之为Joint Venture(以下简称JV)。与此同时，复杂的组织形式和多方的协作问题以及跨境数据的流动也带来了更多的安全问题。本篇将从架构师视角进行总结，并一探究竟。

0x01 业务篇

这里并不会从市场视角讨论业务，例如：理财，消金，信贷等等；而会关注于支付场景的参与方，以及常见的交易行为。且以下场景均是基于Retail payments 零售支付（Payments between non-financial institutions (e.g. private households, non-financial corporations or government agencies) are normally classified as retail payments.）业务场景讨论的。

1. 支付中的参与方

出于对业务的了解，我们先从日常的几个生活场景来看支付的过程中存在哪些参与方：

• 企业按月将工资存进员工的银行账户；
• 从ATM或者柜台进行取钱，把银行存款变成法币；
• 使用现今购买一杯奶茶，把现金交给店员；
• 使用支付宝或者微信支付等第线上三方支付工具购买一杯奶茶，顾客出示付款码【被扫】，或者【主动】扫描店铺的二维码进行支付从银行卡扣款进行支付或者从余额扣款进行支付（即可以是【主动】扫码，也可以是）；
• 使用美团买券，从银行卡进行扣款。 商户核销券，并给出对应
• 使用银行卡APP进行支付

那在这些支付过程中，显而易见的存在，顾客，商户，支付平台（收单），银行（发卡）。 实际在此背后的则还有一个机构叫做卡组。卡组的主营业务就是负责将对应的支付信息通过对应的路由机制，把相应的数据送到对应的银行里去，并负责完成相应的清结算（包含清分和结算）。在这种模式下，如果发卡和卡组都是一家机构的话，我们称之为三方模式；反之，为四方模式。目前的三方模式的有Discover，AMEX，四方模式的有Visa，MasterCard和银联。

该图引用自European Central Bank的Payment System一文，详细参考见附录。另关于模式不同的详细介绍可以参考之前做的电子支付基础系列分享。两种模式各有优劣， 三方模式虽然重资产、成本高。但由于其介入了支付产业链经营，所以能够直接控制发卡和收单业务，并提供更全面的金融服务。而四方模式定位于支付网络经营和系统建设，生态和规模更易扩展，不仅可以降低服务成本，还能促进行业发展。但需要与多个发卡行和收单行合作，沟通协调成本可能较高。

2. 交易是如何进行的

一笔经典的交易，分为两部分： 授权（Authorization）和清结算（Clearing & Settlement）。这里的交易，并非完全指pay for something,比如借记、贷记的业务类型。而是指发了网络里发生了一笔transaction。在这一笔transcation中可能包含签约、解约、余额查询、退货、通知等业务类型。当然从支付是否需要卡片，这些类型的业务交易还可以区分为持卡交易(Card-Present)和无卡交易(Card-Not-Present)。另外常见的支付协议有ISO8583，ISO20022以及国内独有的以XML表示业务类型以及HTTPS通讯的协议（下文简称XML支付协议）。回归到业务流程本身，我们来看一下授权场景中的流程：

让我们抽象一下，实际就是：

而Acquire System可以是Pos、SoftPos， mPOS、Virtual Terminal， 亦或是Payment Gateway。而实际Acquire system从发起Request到接收到Response的Transaction LifeCycle也不仅如此。在此不再做介绍。

3. 利润是如何分配的

你有没有注意到，无论是在京东购物，还是美团买券，亦或者在携程付款，各个平台都会优先采用自己的支付平台。京东支付，美团支付，程支付，小米支付，Oppo支付等等；

在完成一笔交易的过程中，顾客支付给商户的金额并不会全部最终到商户账户中，通常还包含着通道费，品牌费，手续费，跨境交易费等。而根据费改后机制，如果只考虑手续费，且假设收单机构以5ps分润为例，1亿元的交易中，收单侧可以获利5w元。另根据人行的2024年支付系统总体报告，网联平台的日均交易额在1.42 万亿元（日均处理业务 28.27亿笔）。2023年共处理497.90万亿，2024年共处理520.5万亿元，同比增长4.54%（银联的支付则同比下降8.61%，日均处理业务9.14亿笔，为6979.66亿元，两者一个是处理日均万亿，一个是处理日均亿元）。那么也就是对于三方支付平台，每天分得的蛋糕在7250万元左右。不过根据商户类型的不同，费率可能有所不同。但总体来说这依旧是一个每年高达百亿的市场。而且根据最新公示，国内大概有170多家持牌的非银支付机构。而以头部电商、社交业务所衍生的支付平台更是占了大头。无论是出于业务的竞争，还是开展金融业务。电商平台配备自己的支付系统似乎也成为了标配。另外就是这些企业的入场方式，大概率是收购一家持牌公司，逐步注资到完全控股。而除了手续费，对于平台促进的消金业务更是盈利大头，京东白条，蚂蚁花呗，美团先付后花（我难道点个拼好饭都要先付后还？）。在消费主义的促进下，金融证券化工具被玩的眼花缭乱，最终用户的信息以及债务早已不知道被卖了几手。

0x02 技术篇

清算网络出于行业的特殊性，必然不会有非常先进的技术。且出于对支付网络的职责和上下游依赖，保持7x24h的运营也更加的重要。接下来，从多个维度来看在网络中发生了什么？

1. 协议：业务是如何转换为数据流的？

如前文所说，国内的支付系统中，主要基于以下两种协议完成交易：分别是ISO8583支付协议，和XML支付协议。前者基于TCP/IP协议，后者则是基于HTTP/S协议。

从图中也不难看出，收单机构会根据持卡交易还是无卡交易将对应的交易信息上送至网络（即所谓的前置，不过网络侧的前置一般是收单侧的后置，网络侧的后置一般是对接发卡侧的前置），其中无卡支付甚至需要复用已有的8583交易链路。而ISO8583并不是一个新的协议，你可以在下图之中看到，其最早创建于1987年，而最新的版本也是在2003年。其设计的方式是通过bitmap的形式，为每一个标志位设置为不同取值的方式，来完成对业务的mapping。从图中也不难看出整体的消息结构为MTI-BitMap-Data。具体的信息可以根据下图进行学习。

其中针对字段的保留，取值，以及消息的类型（单双消息）设置也不尽相同。比如AMEX采用双信息交互，即授权和请款分为两次，银联则采用一次请求即可。所以即便采用同一种ISO8583的协议，但出于属地化的不同，和卡组的设置。也仍需进行一定的转换。

XML本身不打算在此介绍，毕竟不具有代表性，但出于文章完整性考虑。仍放置此处。其主要通过XML的字段对业务进行Mapping，并通过HTTP/S协议进行交互，但是也如前面所述，一定情况下，该类报文仍会被转换为ISO8583完成后续的switching，这是出于历史考量的设计，虽然并不是最优的设计。

另外ISO20022没有在此处介绍，ISO20022也是基于XML Schema的，但相对更加规范。XML本身一是可以携带更多的信息，二是所有的数据更易读。从国内的XML协议可窥一斑，不同国家domestic的支付协议也不尽相同。基于两大需求，在Swift的推动下，国际批量支付的已经逐步向ISO20022切换，感兴趣的可以自行了解。另外随着新技术的发展，协议也是在发展，前段时间在学习CBDC的过程中，发现BIS也通过mBridge项目使得各国CBDC得以互换。其中涉及的细节感兴趣也可以了解一下。

2. 网络：如何链接到清算数据中心？

这篇地方的网络终于回归到技术人理解的网络了，没错就是IT含义的Network。数据的交互无论通过什么协议进行总是要经过传输的。在清算网络中出于对安全性和稳定性的要求。往往会要求机构（此处代指发卡侧和收单侧）通过专线和前置机的形式链接到网络中去。更有甚者，存在前置机房以供机构参与者接入。前置机有的会完成一部分针对OS的基线控制等，或者是定制的OS，当然有的前置机可能只是部署一套特定的应用程序（例如部分银企直联的前置系统）。

然而即便在国内的推广两地三中心模式的情况，实际展业的过程中，也仍然存在单区域单机房的展业情况。至于为何，不得而知。另外除物理的专线外，在网络协议层面，还可以通过IpSec协议进行链接。而如果需要维护网络层面的高可用，则一般是多路专线，并选择不同的运营商。或者是一路专线，一路IpSec VPN打通，这取决于卡组对接入网络的要求。而回归到清算网络本身，也会基于主流的网络架构实现高可用。以Spine-Leaf架构为例：

而如果是存在多个机房，则又通过各自机房的border leaf交换机进行专线连接，以实现稳定的传输。

这样每个DC有两个可确保不会发生任何边界Leaf故障而导致DC被隔离。即便单个DC网络故障，应用和服务仍然可以故障转移到幸存的DC，利用VXLAN EVPN提供的扩展L2/L3网络。对网络更底层的知识，我没那么专业了，就不在此班门弄斧了。如果有兴趣，可以通过阅读华为最新AI数据中心网络架构进行系统化学习，对比一下，AI化的数据中心和金融数据中心的区别。

3. 应用：有哪些核心系统和周边系统？

前面讨论了业务通过ISO8583协议和XML协议进行mapping，并转换为数据流。然后通过可信网络（专线、IpSec等）进行TLS传输，那么针对核心的Switching和Clearing & Settlement之外，有哪些系统支撑业务的完整运行呢？让我们继续一窥究竟。

首先从系统维度来看，整体以清算网络的核心（转接和清算）并围绕核心建立起来的系统。如下图所示，转接部分已在前面部分讲过，不再赘述。清算部分关系到资金的清分和结算，因此除却资金划付系统、清分系统，还有文件收发系统、支付标记化系统、差错系统、风险系统等。当然风险系统同时也会作用于转接过程，即所谓的实时风控。在整个过程中文件收发系统作为网络内的上游数据系统，收集来自不同源的数据并给到内部系统进行消费。数仓/大数据作为数据中台经过对数据的处理提供给其他业务系统进行消费。

在上图中，作为2B业务，清算网络也只是服务于机构。但是在三方模式之下，卡组在权益相关的优势就体现出来了（前提是权益真有优势才行…..），卡组同时也会面向持卡人服务，即开始存在2C的业务。而围绕着服务持卡人则又引申出了一系列新的系统。包含营销活动管理、用户行为分析、内部的风险管理、黑名单的筛查、对账计费等系统。而清算网络也由此围绕着机构和持卡人开展相应的业务。

最后从应用本身来看的话，其实没太多好讲的。不想去讨论什么先进的还是合适的。如果单体架构能够适应稳定性的情况下，当行业业务属性不需要快速扩容和迅速迭代的话，也无关紧要。只是无论单体架构还是SOA，亦或是Event-Driven（个人私下认为这几种架构更适合支付类业务场景），都能够满足需求即可，但这并不意味着，仍然使用jsp，asp去编写一些程序，即便抛却UI的古老风格，也需要去考虑一下满足202X年代的一些基本实践。更不用提抽象出什么公共框架和组件了，这也是为什么一些简单的改造动辄都需要数百万至数千万，实际不过是政治遗产下的木偶戏罢了。

0x03 安全篇

这里我们暂时不再关注针对整体的安全设计，而是通过交易和支付的视角来看其中的安全控制，感兴趣的话可以翻翻前面写安全架构的博客。也可以参考金融安全架构设计中的反思

金融支付中的一些解决方案图在绘图时往往会用两种流表示数据，一种是信息流，一种是资金流。信息流基本是包括交易指令、账户信息、支付状态、验证信息等。资金流则是指在支付过程中实际资金的流动。但无论是哪种流，实际都是数据在流动，这也是清算网络中对安全更为敏感的部分。而对数据的保护则主要以密码学为基础，通过对成密钥加密，PKI体系，和混合加密三种主要技术领域进行。这里就只讲讲基础的证书和密钥了（其实是画图也画累了💤）。至于支付标记化（Tokenization，还是挺重要的）是加密的另一种应用方式，以及3DES和AMEX基于3DES的SafeKey如何使用生物认证完成授权动作后续再讲。

1. 证书与无卡快捷支付

• 针对XML报文启用证书完成HTTPS传输加密
• CSR直接从HSM产生
• 证书来自公签CA
• 使用证书校验证书的有效期，及CRL列表，及证书链
• 签名验签和加密解密的Key Usage分离，做成两张证书
• 加密解密的证书私钥来自CA
• 对敏感信息使用加密证书进行加密
• 在报文尾部针对报文主体进行签名
• 发布网络的验签证书给到所有机构，并加载所有机构的验签证书

其余具体使用流程可以直接参考上图即可。其他的还需要关注证书在卡片上的应用，如何通过证书实现防伪；以及如何通过证书完成相关运营系统的登录认证；如何通过硬件Key进行灌注确保私钥的安全等。

2. 密钥与传统持卡交易

关于密钥与持卡交易，如果只想大致了解，可以参考此图：

详细了解，则需要参考下图：

• 在HSM中创建对称密钥，并通过密钥信封分别快递给对应接收人
• 接收后将两到三个密钥信封的分量合并导入到接收方HSM中，使用各自机构的主密钥进行保护
• 双方分别各自同步该密钥到各自HSM集群中
• 根据密钥进行派生出工作密钥，即Data Key，包含Mac Key和Pin Key。并用于加密对应数据及生成对应MAC值（HMAC）
• 根据约定的填充方式针对ISO8583报文启用关键字段加密，或针对Full Message进行加密
• 接收方根据报文校验值进行检验
• 卡组针对收单侧信息进行解密后，在向后的路由过程中使用发卡侧预先同步的密钥进行加密

其他需要关注的还有如何通过混合加密体制，例如非对称包裹一次性对称密钥；以及PGP的应用等，及如何通过使用Key Block格式（TR-31格式）使Key本身具备使用约束，并能够更安全的完成密钥同步等。关于TR-31的知识，请参考ANSI X9.143-2022。

0x04 运营篇

之前的博客曾提到过，传统金融行业中更加注重流程的管理及运营，以此实现安全和稳定的目标。清算网络则更胜一筹，对既有流程运营的依赖更是根深蒂固。出于有限的市场参与者，这使其整体处在了一种“又不是不能用”的运营水平上。就像有人会说：只有几十家接入机构的情况下，为什么还要用DNS，而不是全部硬编码IP。这个理由看起来很充分，做好台账就行了嘛！

1. 从机构入网开始

无论前文中针对密钥的分发还是证书的交换，亦或是专线的接入。这些动作最早发生在机构接入清算网络的过程。（后续存在的定期更换放到下一小节）。

• 资质审核与协议签署： 这里需要入网机构提供一系列的凭证资料，合规资料。例如持有相应的经营许可证，具备反洗钱措施；
• 关键资源申请及配置： 包含了从机构代码（作为清算网络中的唯一标识）的申请，到卡BIN的申请，清算信息的配置等等；关键平台的权限申请，例如商户管理平台，差错管理平台，风险管理平台等；
• 背书及认证： 终端要做认证，卡片要做认证，机构要过一些合规的认证（PCI-DSS认证，UPDSS认证，等保认证等）；
• 密钥及证书： 签名验签的证书申请，双应用证书的申请，平台运营用户的登录证书申请等；
• 接入及系统调试开发：开始物理链路专线接入，然后根据离线测试（本地测试），联机测试（类似UAT），Beta测试（类似线上测试）
• 投业

注意，以上步骤仅为列述，并非强烈依照时间先后顺序进行。但这些步骤强体现了如何多部门协作下的复杂运营以及台账文化共同支撑了机构入网直至展业的整个过程。 其中几乎每个流程都需要多部门/多节点的审批，常规情况下每个流程5个工作日能审批完已经不错了。这并不是说效率很高很严谨，也不是说大家很忙或者没事干。

2. 流程及流程例外

有流程，则一定是有例外管理。流程的运营固然能起到安全的控制作用。但实际上因为流程只能限定在自己的企业部分（一般不能侵入到别的企业中，或者话语权非常强）。而在这种情况下，安全控制中流程的不对等性间接导致了安全的不对等性，进而导致安全控制失效。 就像我之前博客曾记录过的，网络通过严格的密钥管理员机制多路寄出密钥信封给到机构A，对侧机构虽然两个人接收了，但是两个人拿到一起，拆开，输入到TXT文件，拍照给你。复核的流程确实严谨，只是用错了方法。所以及更应通过技术来确保，而非流程。

日常的运营过程中，很多流程都是依赖于台账，通过归档Excel申请表，营业执照复印件来记录台账；通过加盖公章来说明效力，通过多个部门参与来分摊责任成本，通过自签署声明表示知晓，并通过合同后约束法律效益。但这种流程不能深究，他不像1是1，2是2这么有板有眼，任何流程的实现都有操作的空间，有时候甚至无法说明流程的必要性及有效性。更多的流程及例外需要自行思考是否有效。先做后补流程？更新流程的参与范围？如何评定流程的有效性？当然也有一些业务流程的设计非常漂亮，例如Global Authorization Network的失效会自动传输数据到GAN Issuer Gateway。

3. 监管及监管合规

监管是金融行业参与者的生死线，给你例外能让你整改，不给你例外那就难堪了。此处话题高端，不做讨论。仅通过一些监管的项目来说明对安全的重要性。不一定是技术安全，既可以是流程上的，也可以是资金上的。仁者见仁，智者见智。

• 断直连：人民银行“断直连”工作要求，第三方支付机构全部接入银联或网联系统，商业银行与支付机构之间的业务，城银清算有限公司和农信银资金清算中心成员机构与第三方支付机构之间的业务不再计入商业银行行内业务系统、银联清算支付清算系统和农信银支付清算系统业务量统计。
• 商密改造工作：算法迁移到SM4，SM2
• 商户信息报送：三方支付报送商户信息
• 交易个人隐私信息数据保护： ISO8583报文敏感字段加密，XML报文敏感字段加密