AI-Native 技术决策者速查手册

场景触发式 · 三步清单 · 即查即用

使用说明

别按时间学，按事件用。
遇到以下6种场景时，打开对应章节，复制Prompt，做完打钩。

场景一：技术选型（买什么/用什么）

触发条件：要选型时序数据库/MES/中间件/云厂商，或评估自研vs外采

三步操作

步骤 你做什么 给AI输入 拿到结果
1. 填约束卡 列出绝对不能碰的红线（预算/性能/协议） 见下方【约束卡模板】 3个AI对齐的约束清单
2. 三方会审 同一问题问Kimi、Claude、DeepSeek 见下方【选型Prompt】 3个方案+风险雷达图
3. 找死亡条件 对比AI答案差异，标记"什么情况下会炸" "哪个方案在[具体约束]下会死？" 选型决策+风险档案

约束卡模板（复制填写）

硬性约束（一票否决）：
- 预算上限：___万（含三年维护）
- 协议要求：必须开源（Apache 2.0/MIT）或商用授权<___万
- 性能基线：支持___并发，延迟<___ms，离线运行>___小时
- 兼容性：必须支持___（如：IE11/Win7/ARM32）

软性约束（可妥协）：
- 社区活跃度：GitHub>___stars，最近commit在___个月内
- 中文支持：文档/社区/工单
- 团队技能：现有技术栈匹配度（Java/C#）

绝对不能接受的：
- [ ] 云厂商锁定（如只能用阿里云）
- [ ] 单点故障无降级方案
- [ ] 数据 stored in 境外

选型Prompt（复制粘贴）

角色：工业IoT架构师（50租户，4万点/秒，边缘离线72小时）
约束：[粘贴上方约束卡]

任务：对比[选项A/选项B/选项C]在以上约束下的适用性

要求：
1. 给出3个方案的架构图（Mermaid）和TCO（精确到$/年）
2. 每个方案必须说明"死亡条件"：在什么具体参数下会爆炸（如：数据量>1亿行时查询超时>10秒）
3. 给出唯一推荐，并说明"如果这个推荐错了，最可能是因为忽略了哪个约束"

禁止：不要说"根据需求选择"，必须给出明确排序。

检查清单（做完打钩）

场景二：审代码/审方案（查作业）

触发条件：收到AI生成的代码、外包提交的方案、同事设计的架构，需评估可靠性

三步操作

步骤 你做什么 给AI输入 拿到结果
1. 闭眼画流 遮住代码，手绘数据流向（从哪进→到哪出） 纸笔草稿 你的预期架构图
2. 差异找茬 看AI代码，对比你画的图，找"多出来的线"或" missing的线" 见下方【审代码Prompt】 边界漏洞清单
3. 灵魂三问 让AI回答极端情况 见下方【三问Prompt】 风险修复方案

审代码Prompt（复制粘贴）

角色：代码审计专家（专找边界条件漏洞）

代码上下文：
[粘贴AI生成的代码或方案描述]

审计要求：
1. 找出3个"隐藏炸弹"：在[并发50/断网/数据为空/内存不足]时可能爆炸的点
2. 必须具体到行号：第___行如果___会发生___
3. 给出防御性代码建议（带注释说明为什么）

禁止：不要说"代码看起来不错"，必须找出问题。

灵魂三问Prompt（复制粘贴）

基于以上代码，回答以下三个极端场景（必须具体到数字）：

1. 并发场景：如果同时50个租户执行此操作，哪行代码会先卡死？CPU会到多少？
2. 故障场景：如果此时kill -9或断网，数据会停在什么状态？会丢多少条？
3. 注入场景：如果输入是null/超长字符串/SQL注入攻击，第几行会崩溃？

如果答不出具体数字，说明此代码未经过压力测试，标记为高危。

检查清单

场景三：解决线上故障（救火）

触发条件：系统卡顿/报错/数据丢失，需快速定位和止血

三步操作

步骤 你做什么 给AI输入 拿到结果
1. 喂现场 收集现象（报错/监控/最近变更） 见下方【现场卡模板】 AI的假设树
2. 验假设 让AI给出验证命令，你执行后反馈 "验证第1个假设的命令是什么？" 根因确认
3. 防再犯 让AI抽象为模式，固化到知识库 见下方【复盘Prompt】 故障模式卡片

现场卡模板（复制填写）

现象描述：
- 错误表现：CPU 100% / 内存溢出 / 连接超时 / 数据丢失
- 发生时间：___（是否规律性，如每天下午3点）
- 影响范围：___租户 / 全部 / 随机
- 监控数据：QPS___/内存___%/连接数___

最近变更：
- 上周发布了___功能
- 昨天修改了___配置
- 刚接入___设备

已尝试：
- [ ] 重启（效果：___）
- [ ] 回滚（效果：___）
- [ ] 扩容（效果：___）

救火Prompt（复制粘贴）

角色：SRE故障排查专家

现场信息：[粘贴上方现场卡]

任务：
1. 列出3个最可能的原因（按概率P0/P1/P2排序），并说明判断依据
2. 给出验证每个原因的**具体命令**（如：SHOW PROCESSLIST; 或特定日志grep）
3. 给出**立即止血方案**（不停机/不丢数据的临时缓解措施）
4. 给出**根治方案**（防止复发）

要求：
- 不要说"可能网络问题"，必须具体到"第几台机器的哪个网卡"
- 必须评估：如果我的诊断错了，执行方案会导致什么后果（数据丢失？服务中断？）

检查清单

场景四：学新技术/啃文档（调研）

触发条件：要学Bytebase/K8s/TDengine，或读官方文档抓重点

三步操作

步骤 你做什么 给AI输入 拿到结果
1. 问本质 不问怎么用，问解决什么痛点 "用3句话告诉我..." 核心定位
2. 出考题 让AI出反直觉的判断题 见下方【考题Prompt】 知识盲区暴露
3. 找嫁接 问能否用到现有项目 "这个思想能移植到___吗？" 跨域模式

快速入门Prompt（复制粘贴）

我要在20分钟内决定是否使用[技术名称]（如Bytebase）。

请用3句话回答：
1. 它解决什么**具体痛点**？（必须用类比，如"像Git管理代码一样管理数据库变更"）
2. 不用它，传统做法**最痛的一点**是什么？（具体到操作步骤）
3. 它最适合什么**数字条件**？（如：表数量>100/团队>10人/变更频率>每天5次）

禁止：不要说"它是下一代XX平台"，必须说人话。

考题Prompt（复制粘贴）

假设我是个新手，你出3道**判断题**，答案是**反直觉**的（很容易猜错的那种）。

要求：
1. 题目必须涉及[技术名称]的**边界限制**（如：最大连接数/不支持的操作/性能陷阱）
2. 给出答案并解释**为什么容易错**（即：AI或其他技术在这个点上容易混淆）

目的：帮我建立"这个技术不能做什么"的直觉。

检查清单

场景五：写代码/做需求（日常搬砖）

触发条件：要开发新功能、优化查询、对接硬件/MQTT

三步操作

步骤 你做什么 给AI输入 拿到结果
1. 下Brief 写约束卡（比功能描述更重要） 见【需求卡模板】 3个实现方案
2. 要测试 让AI先写测试用例，再写代码 "生成边界测试用例" 验收标准
3. 问Why 让AI解释每行关键代码的存在理由 "解释第X行为什么存在" 删除冗余代码

需求卡模板（复制填写）

功能：___（如：多租户报表导出）

绝对不能出现的（红线）：
- [ ] OOM（内存必须<___%）
- [ ] 阻塞其他租户（隔离性）
- [ ] 兼容性问题（必须支持___浏览器/系统）

数据规模：
- 正常：___行/秒
- 峰值：___行/秒（持续___分钟）
- 最大单文件：___行

特殊约束：
- 合规：数据不能出境/必须加密
- 业务：必须支持离线查看/必须保留___天历史

开发Prompt（复制粘贴）

角色：资深Java后端（Spring Boot + MyBatis-Plus）

需求卡：[粘贴上方内容]

任务：
1. 给出3个实现方案（简单版/平衡版/豪华版），说明各自的取舍
2. 我选定方案后，**先写出核心逻辑的伪代码**（我确认后再生成完整代码）
3. 生成**防御性测试用例**（测试边界条件：如输入100万行/null/并发50）

约束：
- 代码中必须显式处理tenant_id注入（多租户）
- 必须标注"此处如果在___情况下会阻塞"（风险提示注释）

代码审查Prompt（复制粘贴）

请解释这段代码中，第___行到第___行的存在理由：

要求：
1. 如果是为了处理___边界条件，请说明触发频率（每秒钟/每天/极少）
2. 如果删除这行，系统会在什么情况下崩溃？
3. 如果这行是性能瓶颈，优化后的代码长什么样？

如果解释不清，建议删除或重构。

检查清单

场景六：复盘/沉淀（防重复踩坑）

触发条件：项目结束/故障修复/选型落地，需总结经验给未来用

三步操作

步骤 你做什么 给AI输入 拿到结果
1. 喂上下文 描述背景+决策+结果 见【复盘卡模板】 模式抽象
2. 挖死亡条件 问"这个方案在什么情况下绝对不能用" 见下方【死亡条件Prompt】 风险边界
3. 入档案 让AI生成标准格式，提交Gitea "生成Markdown模式文档" 可复用资产

复盘卡模板（复制填写）

背景：
- 当时面临的问题：___（如：50租户查询卡顿）
- 可选方案：A___ B___ C___
- 最终选择：___
- 约束条件：___（当时的硬性限制）

结果：
- 预期效果：___
- 实际效果：___（量化：延迟从___降到___ms）
- 出现的意外问题：___

模式提取Prompt（复制粘贴）

基于以下复盘卡，抽象为**可复用决策模式**：

[粘贴复盘卡]

要求生成：
1. **触发条件**：什么场景下可以直接套用此模式（具体到数字，如：租户>30且预算<10万）
2. **决策树**：if [条件] then [方案A] else [方案B]（MECE无遗漏）
3. **死亡条件**：此模式在___情况下绝对会失效（3条具体红线）
4. **AI警告**：下次让AI生成此类方案时，AI容易在哪个点瞎给建议（如：AI总是建议Redis Cluster但忽略了客户端复杂度）

格式：Markdown，可直接存入知识库。

检查清单

通用防幻觉守则（所有场景通用）

AI容易犯的错（你的检查重点）

  1. 忽略物理限制：AI建议"上K8s"但没考虑你只有2台机器
  2. 混淆版本：AI用已废弃的API（如MyBatis-Plus 3.5的写法在2.x不支持）
  3. 忽略边界：AI写代码不判空/不限流/不处理并发
  4. 过度设计：AI为了"优雅"增加不必要的抽象层（如为了个简单查询引入Kafka）

遇到冲突时（Kimi说A，Claude说B）

  • 立即标记为高风险区：AI分歧越大，说明这个点越容易踩坑
  • 人工查证：去官方文档/GitHub Issues找真实案例，不要信任何单一AI

每日最低限度（防崩底线）

即使今天再忙，只要用了AI，必须完成：

打印此页，贴显示器旁。遇到对应场景，打开即用。

posted @ 2026-02-07 10:40  WinChance  阅读(13)  评论(0)    收藏  举报