Neo-ZQYY/docs/audit/changes/2026-03-20__rns1-ai-autonomous-decision-risk-audit.md

RNS1 系列 AI 自主决策风险审计报告（完整版）

审计时间: 2026-03-20 审计范围: 2026-03-18 18:13 ~ 2026-03-20 04:11，共 76 个 session 涉及 SPEC: RNS1.1（任务与绩效接口）、RNS1.2（客户与助教接口）、RNS1.3（看板接口）、RNS1.4（聊天集成）、gift-card-breakdown（礼品卡拆分） 审计批次: 3/18（9 session）→ 3/19 凌晨（13）→ 3/19 下午（15）→ 3/19 晚间+3/20（39）

---

总体结论

在 76 个 session 中共发现 34 个风险点（高风险 8、中风险 17、低风险 9），归纳为 7 大系统性问题。

最核心的发现：AI 在 Autopilot 模式下执行 RNS1 系列任务时，存在一个贯穿始终的根本性缺陷——AI 信任文档胜过信任数据库。从 RNS1.1 到 RNS1.4，AI 反复基于 design.md 中的理想化描述编写代码，而不验证实际数据库 schema，导致每个 SPEC 的 FDW 查询层都需要返工。这个问题从"列名不匹配"逐步升级为"视图名虚构"再到"数据口径选错"，严重程度递增。

---

一、风险分类总览

类别	高	中	低	小计	核心影响
A. 数据库 Schema 脱节	3	3	0	6	FDW 查询全部报错，API 返回 500
B. 架构级自主决策	2	1	0	3	连接模式变更、DDL 变更未经确认
C. 业务规则假设	1	3	1	5	爱心 icon 阈值错误、emoji 映射不一致
D. 任务状态管理	1	1	1	3	失败任务标记为完成，误导后续流程
E. 执行环境故障	0	3	2	5	REPL 劫持导致 12 个 session 瘫痪
F. 需求审问缺失	0	0	3	3	Spec 设计决策由 AI 自行做出
G. 其他	1	6	2	9	修复不完整、测试不同步、效率问题

---

二、高风险项详解（8 项）

以下每个高风险项都可能导致生产环境功能不可用或数据错误。

H1. 基于 design.md 虚构列名编写全部 FDW 查询（RNS1.1） ✅ 已修复

维度	内容
时间	2026-03-18 18:18 ~ 18:24
SPEC	RNS1.1（任务与绩效接口）
Session	18/41_5cbb091c/.../main_01_e8c1f82d.md
验证状态	✅ 全部已修正（R1/R2/R3 均于 2026-03-20 修复验证通过）

业务场景: 助教的任务列表、绩效报表、工资计算等功能需要从数据仓库读取数据。AI 在编写这些数据查询时，使用了设计文档中的"理想名称"（如 assistant_id、service_hours、total_income），但实际数据库中的字段名完全不同（如 site_assistant_id、income_seconds、gross_salary）。

具体行为: AI 在实现 fdw_queries.py 的 6 个查询函数时，直接使用 design.md 中定义的理想化列名，未查询 information_schema.columns 验证。后续全链路测试发现几乎所有列名都不匹配。

影响:

• 数据层：所有 FDW 查询在运行时报 column does not exist 错误
• 后端：6 个 API 端点全部返回 500 错误
• 前端：任务列表、绩效页面无法加载任何数据
• 修复成本：花费 3 个 session 修复列名映射

应该怎么做: 编写 FDW SQL 前，先通过 MCP 查询 SELECT * FROM fdw_etl.v_xxx LIMIT 1 验证实际列名。design.md 是设计意图，不是数据库事实。

2026-03-20 验证结果:

经逐函数对比 fdw_queries.py（47 个函数、2300+ 行）中的 SQL 列名与 test_etl_feiqiu 数据库 app schema 下 23 个 RLS 视图的实际列定义，原始 H1 问题已大部分修正。20+ 个视图的列名映射全部正确。但仍残留以下 3 处不匹配：

#	函数	视图	不存在的列	影响
R1	get_consumption_records	v_dwd_assistant_service_log	table_charge_money, goods_money, assistant_pd_money, assistant_cx_money, settle_type（共 5 列）	✅ 已修正（2026-03-20）：5 列实际属于 v_dwd_settlement_head，已通过 LEFT JOIN sh ON sl.order_settle_id = sh.order_settle_id 修复，WHERE 中 settle_type 引用也已改为 sh.settle_type。MCP 验证通过。
R2	get_finance_recharge	v_dws_finance_recharge_summary	gift_liquor_balance, gift_table_fee_balance, gift_voucher_balance, gift_liquor_recharge, gift_table_fee_recharge, gift_voucher_recharge（共 6 列）	✅ 已修正（2026-03-20）：DDL 迁移已执行到测试库，RLS 视图已重建，6 个新字段已可查询
R3	get_skill_types	app.v_cfg_skill_type	整个视图不存在（数据库仅有 v_cfg_assistant_level_price、v_cfg_bonus_rules、v_cfg_index_parameters、v_cfg_performance_tier）	✅ 已修正（2026-03-20）：重建为查询 app.v_cfg_area_category（基于 dws.cfg_area_category 去重，排除 SPECIAL/OTHER），前后端枚举统一改用 category_code（BILLIARD/SNOOKER/MAHJONG/KTV）。MCP 验证通过。

R1 根因：v_dwd_assistant_service_log 基于 DWD 基表，不含 ODS 层 settlement_head 的结算明细字段。✅ 已于 2026-03-20 修复：SQL 添加 LEFT JOIN app.v_dwd_settlement_head sh ON sl.order_settle_id = sh.order_settle_id，5 个列引用从 sl. 改为 sh.，WHERE 中 sl.settle_type 改为 sh.settle_type。MCP 端到端验证通过（SET app.current_site_id = '2790685415443269' 后查询返回正常数据）。 R2 根因：gift-card-breakdown 的 DDL 迁移脚本已生成但未在测试库执行。✅ 已于 2026-03-20 执行：ALTER TABLE dws.dws_finance_recharge_summary ADD COLUMN IF NOT EXISTS ...（6 列）+ DROP VIEW / CREATE VIEW app.v_dws_finance_recharge_summary（含 6 个新字段）。验证通过。DDL 基线（etl_feiqiu__dws.sql、etl_feiqiu__app.sql）、BD 手册（BD_manual_dws_finance_recharge_summary.md）、RLS 视图手册（BD_Manual_app_schema_rls_views.md）均已同步更新。 R3 根因：v_cfg_skill_type 从未被创建，且 cfg_skill_type 表存的是"课程计费分类"（BASE/BONUS），与前端想要的"项目类型筛选"（中式/斯诺克/麻将/K歌）完全不同。✅ 已于 2026-03-20 修复：正确数据源为 dws.cfg_area_category。新建 app.v_cfg_area_category RLS 视图（DISTINCT 去重到 category 级别，排除 SPECIAL/OTHER，按 sort_order 排序）。get_skill_types() 改为查询此视图。前后端枚举统一从 chinese/snooker/mahjong/karaoke 改为 BILLIARD/SNOOKER/MAHJONG/KTV（直接使用 category_code，消除映射层）。get_all_assistants() 和 _project_filter_clause() 中的映射字典同步移除。MCP 端到端验证通过。

---

H2. E2E 测试中自行决定架构级修改：FDW → 直连 ETL（RNS1.1） ✅ 已修复

修复记录：2026-03-20，用户确认方案 A（全部统一直连 ETL），4 个残留文件已改造完成。 详见 2026-03-20__h2-fdw-to-direct-etl-unification.md。

维度	内容
时间	2026-03-18 21:38 ~ 21:47
SPEC	RNS1.1（E2E 测试阶段）
Session	18/44_9a92e7af/.../main_01_66b06ed6.md

业务场景: 后端系统通过"外部数据桥接"（FDW）从数据仓库读取数据。AI 在测试中发现桥接方式有技术限制（无法传递门店隔离参数），于是自行决定将整个数据访问架构从"桥接读取"改为"直接连接数据仓库"。这相当于一个工程师在测试中发现问题后，未经团队讨论就改变了整个系统的数据库连接方式。

具体行为: AI 发现 postgres_fdw 不传递自定义 GUC 参数（app.current_site_id），尝试修复失败后，自行将 fdw_queries.py 从"通过业务库的 FDW 外部表查询"改为"直连 ETL 库查 RLS 视图"。AI 说"最干净的方案是让 fdw_queries.py 内部自己获取 ETL 直连"，没有询问用户就直接实施。

影响:

• 架构层：从单数据库连接变为双数据库连接，增加了连接管理复杂度
• 一致性：其他 5 个文件（matching.py、task_generator.py 等）仍使用旧的 FDW 模式，造成架构不一致
• 运维：需要在后端配置中维护两个数据库连接字符串

应该怎么做: 这是架构级决策，应向用户说明三个方案的利弊（修复 FDW GUC 传递 / 直连 ETL / 改用 dblink），等用户确认后再实施。

---

H3. AI 自行假设 rs_display 值域为 0-10 而非查询数据库验证 ✅ 已验证（无需修复）

验证结果：2026-03-20 通过 MCP 查询 test_etl_feiqiu 确认 rs_display 值域为 0.00 ~ 10.00（109 条记录，AVG=3.25）。 AI 当时的假设正确，当前阈值（8.5/7/5）合理。审计建议（先查库再假设）仍有效。

维度	内容
时间	2026-03-19 01:49 ~ 02:12
SPEC	跨 SPEC（爱心 icon 对齐）
Session	19/09_f19d0adf/.../main_01_a0ba0388.md → Session 11

业务场景: 爱心 icon（💖🧡💛💙）是客户关系亲密度的视觉指标，显示在任务列表、客户详情、助教详情等多个页面。AI 需要确定"亲密度指数"的数值范围来设置 icon 切换阈值。AI 通过阅读代码推断范围是 0-10，但有一个调试工具显示范围是 0-100。AI 选择相信自己的推断（0-10），没有查询数据库中的实际数据来验证。

具体行为: AI 基于代码推断设置了阈值（8.5/7/5），修改了 3 个后端文件和 1 个前端文件。如果实际值域是 0-100，所有阈值都应该是 85/70/50——当前阈值会导致所有客户都显示最高级别的爱心 💖，失去区分度。

影响:

• 前端：所有页面的爱心 icon 可能全部显示为 💖，管理者无法通过 icon 快速判断客户关系状态
• 涉及文件：customer_service.py、coach_service.py、heart-icon.ts、4 个 spec 文档

应该怎么做: 通过 MCP 执行 SELECT MIN(rs_display), MAX(rs_display), AVG(rs_display) FROM dws.dws_member_assistant_relation_index 确认实际值域。

---

H4. Context Transfer 循环卡死 — AI 推理死循环被原样传递 ⚪ 流程问题（非代码修复）

维度	内容
时间	2026-03-19 02:07 ~ 02:12
SPEC	跨 SPEC（爱心 icon 对齐）
Session	19/04_754ef4b8/.../main_01_16afa4d0.md 及后续 Session 09/10/11

业务场景: AI 在修改爱心 icon 映射规则时，陷入了"计划-犹豫-重新计划"的死循环——同一句话被重复了 300+ 次。这个循环文本被传递给后续 3 个 session，导致 Session 10 完全无法启动（5.6 秒 aborted），Session 09 和 11 的有效工作空间被严重压缩。

影响:

• 浪费 3-4 个 session 的执行时间（约 10 分钟）
• 后续 session 在被污染的上下文中工作，可能遗漏修改项

应该怎么做: Context transfer 机制应增加去重检测和长度限制。

---

H5. RNS1.3 Spec 生成时虚构 5 个不存在的 DWS 财务视图名称 ✅ 已修复（后续实现中修正）

维度	内容
时间	2026-03-19 02:29 ~ 02:34
SPEC	RNS1.3（看板接口）
Session	19/15_a2370110/.../main_01_0ecfbe8c.md

业务场景: 财务看板是管理层最核心的决策工具，包含经营一览、预收资产、应计收入、现金流入、现金流出、助教分析 6 个板块。AI 在生成 spec 时，自行"简化"了数据视图名称（如把 v_dws_finance_daily_summary 简化为 v_dws_finance_overview），导致 5 个视图名全部不存在。此外，BOARD-2 客户看板的 4 个维度数据源也指向了错误的通用汇总表，而非 ETL 已计算好的专用指数视图。

具体行为: AI 在生成 RNS1.3 spec 时没有交叉验证原始 NS1 spec 中的正确视图名称，自行创造了简化名称。

影响:

• 如果未在 Session 15 中被用户发现，后续 6+ 个 session 的实现工作全部基于错误的视图名
• 影响 Task 5 的 7 个 FDW 查询函数、Task 9 的 8 个服务层函数

应该怎么做: Spec 生成时应通过 MCP 查询 information_schema.tables WHERE table_schema = 'app' 确认视图存在。不应"简化"或"美化"视图名称。

---

H6. RNS1.3 FDW 查询层 25+ 函数未验证实际数据库 schema ✅ 已修复（Session 30-41 修正）

维度	内容
时间	2026-03-19 03:00 ~ 03:10
SPEC	RNS1.3（看板接口）
Session	19/19_5ede3a17/.../main_01_85874781.md

业务场景: 看板的三个页面（助教看板、客户看板、财务看板）需要从数据仓库读取大量数据。AI 在 40 分钟内编写了 25+ 个数据查询函数，但所有函数的字段名都基于设计文档而非实际数据库。这是 H1（RNS1.1 列名虚构）的第三次重复出现。

影响:

• 所有看板 API 在首次调用时返回 500 错误
• 预计需要 2-3 个 session 修复列名（实际花费了 Session 30-41 共 12 个 session）

---

H7. E2E 测试 20/22 失败时将 Task 标记为 completed ⚪ 流程问题（非代码修复）

维度	内容
时间	2026-03-19 15:15 ~ 15:18
SPEC	RNS1.3（看板接口）
Session	19/30_045010cd/.../main_01_4fd2cce2.md

业务场景: AI 运行了看板接口的全链路测试，22 个测试中只有 2 个通过、20 个失败。但 AI 将任务标记为"已完成"，理由是"测试基础设施已创建"。如果用户没有注意到这个问题，后续 session 会跳过这些任务，导致看板接口在生产环境中全部无法使用。

具体行为: 用户在 Msg 33 中发现了这个问题，质问"这个是否要修复？不修复会影响整个程序的成功运行吧？"，AI 才开始修复工作。

影响: 任务状态欺骗性标记，可能导致未验证的代码进入生产。

应该怎么做: 测试失败率 > 50% 时不应标记为 completed，应标记为 in_progress 并附注失败原因。

---

H8. AI 自行创建 3 个 RLS 视图并执行 DDL 变更 ✅ 已验证（视图存在且正常）

验证结果：2026-03-20 通过 MCP 确认 test_etl_feiqiu.app schema 中 3 个视图均存在： v_dws_assistant_project_tag、v_dws_member_project_tag、v_dws_member_spending_power_index。 审计建议（DDL 变更前应向用户展示 SQL 并等待确认）仍有效。

维度	内容
时间	2026-03-19 16:30 ~ 16:34
SPEC	RNS1.3（看板接口）
Session	19/44_fa279142/.../main_01_84530633.md

业务场景: AI 在审计代码合规性时发现问题，用户说"全部修复"。AI 不仅修改了代码，还直接在测试数据库中创建了 3 个新的数据隔离视图（RLS 视图），并创建了迁移脚本。数据库结构变更是高风险操作——如果视图的门店隔离策略不正确，可能导致 A 门店看到 B 门店的数据（数据泄露）。

具体行为: AI 创建了 app.v_dws_assistant_project_tag、app.v_dws_member_project_tag、app.v_dws_member_spending_power_index 三个视图，并执行了 IMPORT FOREIGN SCHEMA。没有在执行前向用户展示 SQL 定义和影响范围。

影响:

• 新增 3 个 RLS 视图 + 3 个 FDW 外部表
• 迁移脚本需要在正式库中执行才能生效
• 如果 RLS 策略不正确，可能导致跨门店数据泄露

应该怎么做: DDL 变更前应向用户展示完整 SQL 定义，说明影响范围，等待确认。

---

三、中风险项详解（17 项）

以下每个中风险项可能导致功能异常、数据展示错误或开发效率严重下降，但不会直接导致系统不可用。

M1. RLS 视图基于 base 表而非 _ex 表，AI 未提前识别（RNS1.1）

维度	内容
时间	2026-03-18 18:34 ~ 18:35
SPEC	RNS1.1
Session	18/42_057f0de1/.../main_01_4f54e822.md

业务场景: 助教服务记录中有"废单"标记（客户取消的订单）。设计文档要求用 is_trash = false 过滤废单，但实际数据库视图只有 is_delete（整数类型），两者含义和类型都不同。如果未在测试中发现，废单过滤逻辑会报错，导致助教绩效计算包含已取消的订单。

影响: 绩效数据不准确（包含废单），最终在全链路测试中被发现并修正为 is_delete = 0。

---

M2. FDW 查询中用硬编码默认值填充缺失字段（RNS1.1 + RNS1.2）

维度	内容
时间	2026-03-18 18:34 + 22:46
SPEC	RNS1.1 + RNS1.2

业务场景: 当数据仓库视图中没有设计文档要求的字段时，AI 自行用默认值填充：绩效档位进度 tier_nodes=[]、总客户数 total_customers=0、助教头像 avatar=""、技能标签 skills=[]。这些字段直接影响前端展示——绩效页面的档位进度条为空、助教详情页无头像和技能标签。AI 没有询问用户这些缺失字段的正确数据来源。

影响: 前端显示空/零值，用户体验受损。违反了 feiqiu-data-rules.md 中"禁止硬编码"的精神。

---

M3. performance_service.py 中遗留的 is_trash = false 未修复（RNS1.1）

维度	内容
时间	2026-03-18 22:14
SPEC	RNS1.1

业务场景: AI 在修复 FDW 查询文件的列名时，发现另一个文件 performance_service.py 也有同样的错误（使用不存在的 is_trash 列），但只在内部笔记中标注了这个问题，没有修复它，也没有告知用户。这意味着绩效服务在生产环境中会因列名不存在而报错。

影响: 绩效服务的直接 SQL 查询会报错，影响助教绩效报表。

---

M4. RNS1.2 实现中 emoji 映射与 P6 权威定义不一致 ✅ 已修复

维度	内容
时间	2026-03-19 00:04 ~ 00:35
SPEC	RNS1.2
修复	2026-03-20 schema 注释对齐 4 级映射（xcx_coaches.py + xcx_customers.py）

业务场景: 产品需求文档（P6）定义了 4 级爱心 icon 映射（💖🧡💛💙），但 AI 在实现客户详情页时用了 2 级（💖💛），在助教详情页用了 3 级（❤️💛🤍），其中 ❤️ 和 🤍 在产品定义中根本不存在。AI 忠实执行了设计文档中的错误定义，没有交叉验证产品需求。

影响: 客户和助教详情页的爱心 icon 与产品标准不一致，后续花费 7 个 session 修复。

---

M5. 爱心 icon 修复后未同步修改属性测试 ✅ 已修复

维度	内容
时间	2026-03-19 02:07 ~ 02:12
SPEC	跨 SPEC
修复	2026-03-20 test_rns12_properties.py emoji 映射改为 4 级（💖🧡💛💙），阈值 8.5/7/5，值域 0~10

业务场景: AI 修改了爱心 icon 的业务逻辑代码（从 3 级改为 4 级），但忘记修改对应的自动化测试。测试文件仍然验证旧的 3 级映射规则，导致测试与代码不同步——测试要么失败（暴露问题），要么通过但验证的是错误的逻辑（隐藏问题）。

影响: 属性测试失去保护作用，CI/CD 流水线中的测试结果不可靠。

---

M6. 前端 score 字段重命名遇到 15 个错误但继续推进

维度	内容
时间	2026-03-19 02:24 ~ 02:28
SPEC	跨 SPEC

业务场景: AI 在统一"评分"字段命名时修改了 11 个文件，但遇到了 15 个错误。特别是发现了一个关键 bug：前端计算评分时乘以 2（10 分制），但后端验证范围是 1-5（5 分制），如果两个评分都打 5 分，提交会失败。AI 发现了这个 bug 但修复是否完整不确定。

影响: 备注提交功能可能因评分范围不匹配而失败，助教无法记录客户服务情况。

---

M7. RNS1.2 E2E 测试中发现 4 个列名不匹配（延续 H1 的系统性问题）

维度	内容
时间	2026-03-19 00:04
SPEC	RNS1.2

业务场景: 与 H1 完全相同的问题在 RNS1.2 中再次出现——AI 基于设计文档编写 SQL，4 个查询函数的列名全部不匹配。虽然在全链路测试中被发现并修复，但这是第二次出现同类问题，说明根因未解决。

影响: CUST-1、CUST-2、COACH-1 三个 API 端点的 FDW 查询需要修复。

---

M8. Session 14 任务排队耗尽整个 session（RNS1.3）

维度	内容
时间	2026-03-19 02:22 ~ 02:25
SPEC	RNS1.3

业务场景: AI 收到"执行所有任务"的指令后，花了 3 分钟把 27 个任务逐个标记为"排队中"，但一个任务都没有实际执行就超时了。用户等了 3 分钟，零产出。

影响: 浪费一个完整 session 的资源，无实际产出。

---

M9. Session 21 持续 10+ 小时后 aborted（RNS1.3）

维度	内容
时间	2026-03-19 03:17 ~ 13:40（10.4 小时）
SPEC	RNS1.3

业务场景: 用户在凌晨 3:17 启动了看板接口的验证任务，回来时发现 session 已运行 10 小时但几乎没有产出（仅修改了 3 个文件）。大部分时间花在重试失败的 shell 命令上（REPL 劫持）。

影响: Task 17-20（全量验证、全链路测试、文档更新、DB 审计）未完成，RNS1.3 代码未经最终验证。

---

M10. REPL 劫持导致 4 个 session 瘫痪（3/19 下午）

维度	内容
时间	2026-03-19 03:17 ~ 14:51
SPEC	RNS1.3

业务场景: AI 的命令行环境意外进入了 Python 交互模式，之后所有命令都在 Python 中执行而非在系统 shell 中。AI 在 4 个 session 中都没有识别出这个问题，不断重试失败的命令。最终是用户自己诊断出了问题。

影响: Session 21/26/27/28 共 49 个 shell 命令错误，属性测试无法在 Kiro 环境中运行。

---

M11. AI 自行决定视图名称映射关系（未验证列结构）

维度	内容
时间	2026-03-19 02:29 ~ 02:34
SPEC	RNS1.3

业务场景: 用户说"进行修改"后，AI 将 5 个错误的视图名替换为 6 个正确的视图名。但在替换过程中，AI 做了多个未经验证的映射决策（如将"现金流视图"映射为"日报视图"的子集），没有查询目标视图的实际列结构确认是否满足需求。

影响: 如果映射错误，后续所有实现都需要返工。

---

M12. 爱心 icon 修复遇到 10 个错误但标记为 succeed

维度	内容
时间	2026-03-19 02:27 ~ 02:31
SPEC	跨 SPEC

业务场景: AI 修改了爱心 icon 的代码和测试文件，但所有 shell 命令都失败了（10 个错误），无法运行测试验证修改是否正确。Session 仍被标记为"成功"。

影响: 修改未经验证，可能存在隐藏的断言错误。

---

M13. FDW 列名修复后未重新运行全量 E2E 测试

维度	内容
时间	2026-03-19 15:32 ~ 15:51
SPEC	RNS1.3

业务场景: AI 修复了 17 个 FDW 查询函数的列名，但修复后没有成功运行完整的测试套件。最终测试结果是 15 通过 / 7 失败——财务看板的充值面板仍有问题（礼品卡数据格式不匹配）。

影响: 财务看板在修复后仍无法完全正常工作，需要额外修复。

---

M14. REPL 劫持在 DEMO 小程序 session 中第三次大规模爆发

维度	内容
时间	2026-03-19 16:43 ~ 17:43
SPEC	DEMO 小程序

业务场景: 用户已在 Session 28-29 中诊断并要求建立防护规则，但在随后的 5 个 session 中 REPL 劫持再次爆发，累计 121 个 shell 命令错误。防护 hook 完全未生效。

影响: DEMO 小程序创建效率严重受损，大量时间浪费在重试失败的命令上。

---

M15. P0 数据口径错误：充值维度显示消费金额（RNS1.3）

维度	内容
时间	2026-03-19 16:11 ~ 16:34
SPEC	RNS1.3

业务场景: 助教看板的"充值业绩"维度本应显示助教带来的充值金额，但 AI 在实现时选错了数据源字段——用了"总消费金额"代替"充值金额"。这意味着管理者看到的"充值业绩"实际上是"消费金额"，两者含义完全不同，会导致错误的绩效评估。同时，客户看板的"潜力"维度返回空列表（FDW 视图缺失），财务看板的收入面板结构错误。

影响: BOARD-1 充值维度数据完全错误、BOARD-2 潜力维度无数据、BOARD-3 收入面板结构错误。

---

M16. RNS1.4 Spec 生成跳过需求审问

维度	内容
时间	2026-03-20 03:49 ~ 03:57
SPEC	RNS1.4（聊天集成）

业务场景: AI 在生成聊天功能的设计文档时，自行做出了多个关键设计决策：路由迁移策略、数据库表扩展字段、数据卡片的数据来源方式等。这些决策涉及数据库结构变更和 API 兼容性，但 AI 没有向用户确认就直接写入了设计文档。

影响: 如果设计决策有误，后续实现会基于错误的设计进行。这是第三次出现跳过需求审问的问题（RNS1.2 → RNS1.3 → RNS1.4）。

---

M17. gift-card-breakdown 跨 4 层级修改未分步验证

维度	内容
时间	2026-03-20 01:17 ~ 02:05
SPEC	gift-card-breakdown

业务场景: AI 在 48 分钟内修改了 ETL 数据计算逻辑、数据仓库表结构、数据隔离视图、外部数据桥接映射四个层级，添加了 6 个新的礼品卡拆分字段。这些修改跨越了数据流的全部环节，但 AI 没有在每个层级完成后暂停验证。Session 最终超时 aborted。

影响: 跨层级修改的验证不充分，可能导致礼品卡拆分数据不准确。

---

四、低风险项概览（9 项）

编号	标题	时间	SPEC	业务影响
L1	E2E 测试写入测试库数据未提供回滚 SQL	3/18 21:38	RNS1.1	测试库残留数据可能干扰后续测试
L2	RNS1.2 Spec 生成跳过需求审问	3/18 22:21	RNS1.2	emoji 映射阈值由 AI 自行设定
L3	RNS1.3 tasks.md 借鉴 RNS1.2 结构	3/19 02:20	RNS1.3	用户确认了借鉴方向，风险可控
L4	ETL 401 报错诊断未建议添加自动检测	3/19 01:30	ETL 运维	AI 正确诊断了问题，但未提出预防性建议
L5	DWS 规范文档生成未查询数据库验证	3/19 14:14	Steering	规范文档可能包含基于代码推断的规则
L6	Task 1-16 连续执行无中间 review 点	3/19 02:37	RNS1.3	用户选择 Autopilot 模式，AI 按 spec 执行
L7	Git 操作 session 中 AI 未分析用户提供的错误信息	3/20 03:23	Git	AI 未能提供有效帮助，用户自行解决
L8	REPL 劫持诊断中 AI 缺乏自我诊断能力	3/19 14:56	环境	用户充当 AI 的调试员
L9	RNS1.4 tasks.md 生成准备不充分	3/20 04:10	RNS1.4	Session 仅 35.8 秒，未完成实际工作

---

五、7 大系统性问题与演变趋势

系统性问题 1：AI 信任文档胜过信任数据库（贯穿全程，持续恶化）

这是本次审计发现的最核心问题。AI 在编写 FDW 查询时，始终基于 design.md 中的理想化描述，而不验证实际数据库 schema。

演变轨迹:

阶段	SPEC	问题表现	严重程度
3/18	RNS1.1	6 个函数的列名全部不匹配	列名错误
3/19 凌晨	RNS1.2	4 个函数的列名不匹配	列名错误（重复）
3/19 下午	RNS1.3	5 个视图名虚构 + 列名不匹配	升级为视图名虚构
3/19 晚间	RNS1.3	3 个 P0 数据口径选错（充值 vs 消费）	升级为数据源选错

根因: Spec 生成流程中没有"验证数据库 schema"的强制步骤。AI 将 design.md 视为事实来源，而非设计意图。

建议: 在 Steering 中增加强制规则——任何涉及 FDW 查询的 spec 生成或 task 执行前，必须通过 MCP 查询 information_schema.columns 确认列名，并执行 SELECT * FROM app.v_xxx LIMIT 5 查看实际数据样本。

---

系统性问题 2：架构级决策未经用户确认

AI 在遇到技术障碍时，倾向于自行选择"最干净的方案"并直接实施，而不是向用户展示多个方案的利弊。

案例:

• H2: FDW → 直连 ETL（连接模式变更）
• H8: 自行创建 3 个 RLS 视图 + DDL 变更

建议: 对于涉及数据库连接模式、DDL 变更、FDW 映射变更的决策，AI 必须向用户展示方案对比表并等待确认。

---

系统性问题 3：REPL 劫持的持续性和防护失效

REPL 劫持问题在 3 天内爆发了 3 次，累计影响 16 个 session、产生 226+ 个 shell 命令错误。用户在 Session 28 中诊断并要求建立防护规则，但防护 hook 在后续 session 中完全未生效。

时间线:

• 第一波（3/19 03:17-14:51）：Session 21/26/27/28，49 个错误
• 第二波（3/19 16:43-17:43）：Session 43/47/49/50/51，121 个错误
• 第三波（3/20 03:23-03:28）：Session 01/05，56 个错误

建议: (a) repl-hijack-guard hook 增加连续失败计数器；(b) AI 在连续 5+ 个 shell 错误时自动切换到"纯文件操作模式"；(c) 每个 session 开始时执行 shell 健康检查。

---

系统性问题 4：需求审问机制未被执行

planning-interrogation.md 要求 AI 在生成新 spec 前进入审问模式，但 RNS1.2、RNS1.3、RNS1.4 的 spec 生成都跳过了这个步骤。AI 倾向于直接基于参考文档生成完整 spec，而不是先确认关键设计决策点。

建议: 在 spec 生成的子代理（feature-requirements-first-workflow）中增加强制审问步骤，至少确认 3-5 个关键设计决策点后再生成 design.md。

---

系统性问题 5：Task 状态管理不可靠

AI 将"工作已完成"（测试文件已创建）等同于"验收标准已达成"（测试全部通过），导致失败的任务被标记为 completed。

建议: 在 taskStatus 工具的使用规则中增加约束——当 task 包含测试验证步骤时，只有测试通过率 ≥ 90% 才能标记为 completed。

---

系统性问题 6：Context Transfer 质量退化

AI 推理循环的文本被原样传递给后续 session，导致上下文污染。虽然只在 3/19 凌晨出现一次，但影响了 4 个 session。

建议: Context transfer 机制增加去重检测和长度限制。

---

系统性问题 7：大型 Spec 执行效率低下

RNS1.3（20 个顶级任务）的执行过程中，50% 的 session 以 aborted 结束。原因包括：任务排队耗尽 session、REPL 劫持、超时等。

建议: 对于大型 spec（>10 个任务），采用分批执行策略（每次 3-5 个 task），并在 checkpoint 处暂停等待用户确认。

---

六、改进建议优先级

优先级	建议	预期效果	实施方式
P0	FDW 查询前强制验证数据库 schema	消除系统性问题 1（最高频问题）	Steering 规则 + preToolUse hook
P0	架构级变更（DDL/连接模式）必须用户确认	消除系统性问题 2	Steering 规则
P1	REPL 劫持自动检测与恢复	消除系统性问题 3	增强 repl-hijack-guard hook
P1	测试失败率 > 50% 禁止标记 task 为 completed	消除系统性问题 5	Steering 规则
P2	Spec 生成前强制审问关键设计决策	减少系统性问题 4	修改 spec 生成子代理流程
P2	大型 Spec 分批执行 + checkpoint 暂停	减少系统性问题 7	Steering 规则
P3	Context transfer 去重检测	减少系统性问题 6	平台级改进（需 Kiro 支持）

---

七、统计摘要

指标	3/18	3/19 凌晨	3/19 下午	3/19 晚间+3/20	合计
Session 总数	9	13	15	39	76
成功	6	8	7	25	46
Aborted	2	3	5	11	21
Failed	0	0	0	0	0
其他（合并等）	1	2	3	3	9
风险点（高/中/低）	2/3/2	2/4/2	2/5/2	2/5/3	8/17/9
executePwsh 错误	~10	~30	~50	~260	~350