Marico's space
最近帮人做技术尽调，遇到一个挺有意思的现象：很多公司的技术团队其实不清楚自己的系统到底"健康"到什么程度。你问他代码质量怎么样，他说"还行吧"；问他数据库设计合理吗，他说"能跑"；问他系统能扛住双十一吗，他说"应该可以吧"。
这种模糊的判断对企业决策来说是很危险的。我做技术审计这些年，逐渐摸索出一套12维度的评估框架，每个维度打分0-10，有对应的风险等级，最后汇总成一份有优先级的行动清单。这套框架帮我快速评估过物流系统、法律科技项目、政府SaaS等各种我之前完全没接触过的系统。
今天把这套框架完整展开说说。不是为了让你机械地打勾勾，而是作为思考系统整体健康度的一个思维模型。
随意检查出来的就是随意的结果。你容易注意到自己熟悉的问题，忽略掉知识盲区，最后给出一份"个人看法清单"而不是客观评估。
打分框架的好处是强制覆盖。而且能生成一份非技术人员也能看懂的产物。CTO不需要关心你用Optional还是T | None，但他需要知道安全评分是4/10，以及三个发现属于OWASP Top 10级别漏洞。
但局限也要说清楚：分数只是起点，不是判决书。架构评分7/10但安全评分3/10的系统，比六个维度都是5/10的系统更危险。上下文很重要。框架告诉你该看什么，判断该怎么做还是得靠人。
看代码之前，先问自己：这套系统的设计架构是什么？实际实现和设计意图一致吗？
关键区分点：
真正要看的东西：耦合度。改一个地方会连锁影响到多少其他地方？高耦合是开发速度慢、缺陷率高的主要推手。
危险信号：模块间循环依赖、业务逻辑堆在controller/route handler里、两千行起步的上帝类、"系统做什么"和"怎么做"之间没有清晰的边界。
框架选型是场暗战。真正要问的是框架怎么被使用的。
我评估这几个方面：
真正在找的东西：可测试性和可调试性。这是可维护性的代理指标。难以测试的代码就是难以安全地修改。
前端评审经常比后端粗糙。这是误区——前端是大多数用户可见bug的藏身之处，也是XSS等安全问题的发源地。
重点看这些：
穿透噪音的问题：如果明天来个初级开发者，他能在10分钟内找到改UI的地方吗？
Schema设计是技术债务凝固成永久形态的地方。烂Schema不会被修复——只会一直被绕过，永远。
我关注这些：
SELECT *吗？ALTER TABLE？最难回答的问题：你们的RTO/RPO是多少？备份策略真的能满足这个目标吗？
设计良好的API是一份契约。烂API是个陷阱——坑前端开发者、坑集成方、坑未来的自己。
评估标准：
GET是幂等的吗？DELETE返回正确的状态码吗？400、422、500有意义区分还是随心情？SELECT * FROM events返回200万行是真的会发生的生产事故。真正要找的东西：API传递的是意图，还是要求调用方了解实现细节？
安全评审这里我要放慢速度。安全漏掉的发现和"代码质量"漏掉的发现，后果完全不同。
我以OWASP Top 10为基准，再加上这些：
认证：凭证用现代算法哈希的吗（bcrypt、Argon2）？有账户锁定机制吗？密码重置安全实现了吗（限时token、一次性使用）？
授权：服务层做授权检查了吗，还是只在路由层？有没有横向权限提升的测试（用户A访问用户B的数据）？
注入：ORM参数绑定能防SQL注入吗——有没有地方用了字符串拼接？用户输入会被传到shell命令吗？
密钥管理：密钥放环境变量（勉强接受）还是硬编码/提交到代码库（不可接受）？.env在.gitignore里吗？
传输安全：强制HTTPS吗？安全响应头有吗（CSP、HSTS、X-Frame-Options）？
找到最多真实漏洞的审计模式：追踪数据。选一条用户提交的数据，从HTTP请求一路跟到数据库再返回。沿途每个转换和校验点都可能是漏洞。
性能问题分两类：现在存在的，以及流量10倍时会出现的问题。
当前状态：
未来状态：
每次评审必问的问题：系统里最慢的操作是什么？它在热路径上吗？
DevOps是软件系统的运维边界。再完美的代码，手动部署到单台服务器也是脆弱的。代码再烂，有扎实的CI/CD、自动回滚、结构化日志，系统就是可控的。
重点看这些：
和应用级DevOps分开的云原生问题：
暴露未审视假设的问题：主region宕机4小时怎么办？给我走一遍流程。
测试是唯一能提供证据（而非信心）证明系统正常运作的机制。
我评估这些：
覆盖率陷阱：测trivial代码达到85%覆盖率，不如关键路径40%覆盖率。覆盖率是代理指标。真正重要的是：你能放心地重构吗？
代码质量是成千上万个小决策积累出来的。我从结构层面评估：
TODO考古层吗——三年前的注释引用一个已经不存在的工单？真正在衡量什么：做一次修改需要的认知负荷。认知负荷高→开发慢→bug多→技术债务多。恶性循环。
2026年了，AI就绪度是头等架构关注点。不是问"你们用AI了吗"，而是"系统设计是否能随着AI能力演进集成AI"。
关键问题：
战略问题：18个月后，竞争对手会有能自动化你们用户30%手工操作的AI Agent。你们的架构让这个成为可能，还是根本不可能？
每个维度0-10分：
| 分数 | 解读 |
|---|---|
| 9-10 | 最佳实践。没有有意义的改进空间。 |
| 7-8 | 稳健。小幅改进边际收益很低。 |
| 5-6 | 够用。有已知差距但无即时风险。 |
| 3-4 | 显著差距。3-6个月内需要改进。 |
| 1-2 | 严重缺陷。需要立即处理。 |
| 0 | 完全未实现。 |
从12个维度得分推导出综合指标：
审计产出四份交付物：
1. 评分卡——12个分数、风险等级（低/中/高/严重）、每个维度一句话发现。
2. 关键问题——风险最高的10个发现，不分维度。这些是可能引发事故、导致数据泄露、或让融资尽调失败的事情。
3. 速赢清单——一周内能搞定、影响不成比例的变化。这些维持团队动能，早期就体现价值。
4. 路线图——中期（1-3个月）和长期（6-12个月）架构改进，粗略工时估算和业务论证。
和工程团队分享结果时，最让他们意外的发现在测试或数据库维度——不是他们至少会焦虑的安全维度。
具体来说：
这套框架是结构化思考的工具，不是思考的替代品。
一个内部工具公司安全评分6/10，和支付公司安全评分6/10，是完全不同的处境。原型系统测试评分4/10可以接受；处理医疗记录的系统4/10是负债。
框架告诉你该看什么。和工程团队、和CTO、和业务负责人讨论，才能确定这意味着什么、该怎么做。
这部分没法自动化。