{"id":"f632f8ed-b1c3-41df-842f-566916bb0b9e","shortId":"2562k8","kind":"skill","title":"p13j-organizational-judgment","tagline":"组织判断力——将个人判断转化为团队判断能力的系统方法","description":"# 组织判断力 Skill\n\n## 适用场景\n- 个人判断无法形成组织能力\n- 团队决策质量不稳定\n- 想建立可持续的判断沉淀机制\n\n## 输入\n| 字段 | 说明 |\n|------|------|\n| team_decisions | 团队重要决策记录 |\n| judgment_outcomes | 决策结果与预期对比 |\n| team_structure | 团队决策流程与角色 |\n\n## 输出\n- 组织判断Checklist\n- 决策会议模板\n- 判断沉淀机制设计\n\n## 工作流程\n1. **判断显性化**：要求团队在决策时明确记录判断依据与置信度\n2. **多元化输入**：确保决策集合了不同视角（引入反对者/外部顾问）\n3. **决策仪式设计**：设计结构化的决策会议流程（如\"预读-讨论-表决-记录\"）\n4. **复盘机制**：定期对照结果回溯判断质量\n5. **原则沉淀**：将有效的判断经验抽象为团队原则\n\n## 注意事项\n- 组织判断 ≠ 民主投票——要明确决策责任人\n- 判断沉淀是长期过程，需要持续记录与复盘\n\n## 核心概念\n\n### 1. 采用阻力不是\"不信 AI\"，而是\"不敢承担某种后果\"\n很多团队一听到用户说\"不想用 AI\"，就默认是观念问题或对新技术的天然保守。其实很多时候不是——用户并不是抽象地排斥 AI，他只是很清楚：如果这一步做错、失控、说不清、或者最后要我来背锅，那我为什么要把它交出去？采用阻力的底层不是意见，而是风险感知。只有把风险感知拆开，产品才有机会真正对症。\n\n### 2. 用户四怕\n(1) 怕错——结果一旦错会影响客户、错误很难被及时发现、错误会扩散到后续流程、用户没有低成本复核手段。用户关注的不是平均表现而是最糟时刻能不能收住。(2) 怕失控——不知道系统下一步会做什么、不能轻易修改或撤销、高风险动作没有确认点、系统把太多决定打包自动完成。用户怕的不是自动化本身，而是自己被排除在控制链之外。(3) 怕担责——如果 AI 给建议但最后还要我签字，这建议是帮我还是多一个我得解释的东西？责任感知常常比能力表现更直接影响采用。(4) 怕看不懂——结果为什么这样？依据是什么？看不懂会让人失去判断自己该不该信的能力。\n\n### 3. 别问\"喜不喜欢\"，要问\"哪一步不敢\"\n访谈中最有效的转法。\"你觉得这个功能怎么样\"\"你会不会用\"这些问题很难触及真正阻力。更有效的问法：你会停在哪一步？哪一步你会想再确认一下？哪一步你绝不会交出去？如果它在这里出错你最担心什么？你最不想替它承担什么后果？一旦这样问，很多\"模糊不放心\"就会变成可以诊断的问题。\n\n### 4. 错误后果地图\n画一张最朴素的地图：这一步如果错了谁先发现？谁先受影响？后果会停在这里还是继续扩散？用户能不能轻易纠正？最后谁来解释？很多采用阻力一画这张图就会突然清楚——用户的害怕不是空穴来风，而是和真实责任链、协作链、后果链紧紧连在一起。\n\n### 5. 把功能问题翻译成心理阻力问题\n\"用户不用自动生成邮件\"不要只理解成\"生成质量还不够高\"，也要追问：他是不是怕发错对象？怕口气不对？怕承诺过头？怕发出去之后要自己解释？功能问题解决的是\"它能不能做\"，心理阻力问题解决的是\"用户为什么不敢交\"。后者的诊断往往比前者更接近采用卡点的真实原因。\n\n## 深入核心概念\n\n### 1. 采用阻力的底层不是意见，而是风险感知\n\n> \"用户并不是抽象地排斥AI，他只是很清楚：如果这一步做错、失控、说不清、或者最后要我来背锅，那我为什么要把它交出去？采用阻力的底层，不是意见，而是风险感知。\" ——书稿第10章\n\n很多团队一听到用户说\"不想用AI\"，就默认是观念问题或对新技术的天然保守。其实很多时候不是——用户只是在评估具体后果。只有把风险感知拆开，产品才有机会真正对症。怕错、怕失控、怕担责、怕看不懂——这四种恐惧各自对应不同的产品设计需求，不能笼统用\"建立信任\"一笔带过。**应用**：对每个采用率低的AI功能，先不要猜\"模型不够强\"，而是做四怕诊断——逐项检查用户到底在怕什么，然后把心理阻力转化为具体设计需求。\n\n### 2. 别问\"喜不喜欢\"，要问\"哪一步不敢\"\n\n> \"更有效的问法：你会停在哪一步？哪一步你会想再确认一下？哪一步你绝不会交出去？一旦这样问，很多'模糊不放心'就会变成可以诊断的问题。\" ——书稿第10章\n\n\"你觉得这个功能怎么样\"\"你会不会用\"这些问题很难触及真正阻力。而\"你会停在哪一步\"\"如果它在这里出错你最担心什么\"\"你最不想替它承担什么后果\"——这些问法会把模糊态度变成具体诊断点。用户不是在抽象评估技术，而是在评估：这件事出了问题，最后落到谁身上。**应用**：设计用户访谈时，把所有\"喜不喜欢\"类问题改写成\"哪一步不敢\"类问题。记录每个\"停\"的位置，那就是托付边界所在。\n\n### 3. 错误后果地图：比功能优化更有用的诊断工具\n\n> \"画一张最朴素的地图：这一步如果错了谁先发现？谁先受影响？后果会停在这里还是继续扩散？用户能不能轻易纠正？最后谁来解释？\" ——书稿第10章\n\n很多采用阻力一画错误后果地图就会突然清楚——用户的害怕不是空穴来风，而是和真实责任链、协作链、后果链紧紧连在一起。后果最重的步骤必须保留人工确认，后果中等的可以让AI先给建议但需要附带依据，后果轻的可以让AI自动处理。**应用**：为关键步骤画后果地图：错了谁先发现→谁先受影响→后果会不会扩散→能不能纠正→最后谁来解释。用这张图决定AI在每一步的进入策略。\n\n## 分步执行\n\n### 步骤 1：采用阻力识别\n观察用户的实际行为：嘴上说还不错但行为上一直绕过你？会让 AI 起草但不会让 AI 发送？会看 AI 总结但不会拿它做会议结论？这类静默绕过比抱怨更值得警惕——它说明表层功能可能成立了，但托付结构并没有成立。\n\n### 步骤 2：四怕诊断\n逐项检查：(1) 怕错——这个场景里最严重的错误是什么？用户有没有低成本复核手段？(2) 怕失控——用户知不知道系统在做什么？能不能修改/撤销/停止？(3) 怕担责——出了问题最后谁来面对客户/老板/合规审查？责任边界清不清楚？(4) 怕看不懂——用户能解释结果为什么这样吗？系统有没有给依据和来源？\n\n### 步骤 3：错误后果地图绘制\n画出关键步骤的后果地图：错了谁先发现→谁先受影响→后果会不会扩散→能不能纠正→最后谁来解释。这张图会帮助你理解用户为什么在某些步骤上特别保守。\n\n### 步骤 4：阻力→设计需求转化\n把诊断出的心理阻力转化为具体的产品设计需求。怕错→需要校验机制和来源标注。怕失控→需要确认点和回退机制。怕担责→需要责任边界清晰化。怕看不懂→需要解释性和可追溯性。\n\n### 步骤 5：访谈问题设计\n设计能触及真实阻力的访谈问题。不要问\"你喜不喜欢\"，要问\"你会停在哪一步\"\"哪一步你绝不会交出去\"\"如果它出错你最担心什么\"\"你最不想替它承担什么后果\"。\n\n## 示例 1：AI 招聘初筛助手——为什么使用率低\n\n**场景**：AI 招聘初筛助手可根据岗位要求和简历内容给出候选人优先级建议。从能力角度看表现不差，但推到用人经理和 HR 手里时使用率很低。\n\n**四怕诊断**：\n1. **怕错**：HR 怕错过合适候选人，后果很实际。\n2. **怕失控**：用人经理不想让系统把人选节奏带偏。\n3. **怕担责**：一旦有人质疑筛选标准，最后需要解释的人不是 AI，而是 HR 和用人经理。\n4. **怕看不懂**：如果系统只给一个分数却不给可解释依据，没人愿意真的依赖它。\n\n**结论**：问题不是一句\"模型还要再强一点\"就能解决的。真正需要的是：(1) 可解释的筛选依据；(2) 允许用人经理调整权重和标准；(3) 明确哪些判断是建议哪些必须人工确认；(4) 出问题时有清晰的回溯路径。\n\n## 示例 2：心理阻力→产品设计需求映射\n\n**场景**：把常见心理阻力映射到具体设计需求。\n\n| 心理阻力 | 典型表现 | 产品设计需求 |\n|---------|---------|------------|\n| 怕错 | \"万一错了客户会投诉\" | 来源标注、不确定项标记、风险句高亮、关键步骤人工确认 |\n| 怕失控 | \"它做了我不知道的事\" | 动作日志、可暂停、可撤销、自动化边界设置 |\n| 怕担责 | \"出了事谁来背\" | 责任边界清晰化——哪些是建议/哪些自动做/哪些必须人工确认/哪些异常升级 |\n| 怕看不懂 | \"不知道它怎么得出的\" | 推理依据展示、来源引用、结果与原始输入对照、关键假设标注 |\n\n**设计原则**：不要一句\"建立信任\"了事，而要把信任需要的条件——依据、控制、回退、责任——变成可以拆、可以改、可以设计的产品结构。\n\n## 示例 3：错误后果地图——以 AI 合同审查为例\n\n**场景**：为一个 AI 合同审查产品绘制错误后果地图。\n\n**关键步骤分析**：\n\n| 审查步骤 | 如果错了谁先发现 | 谁先受影响 | 后果扩散性 | 纠正难度 | 最后谁解释 |\n|---------|----------------|-----------|-----------|---------|-----------|\n| 关键条款遗漏 | 法务审核时 | 公司 | 高（可能损失权益） | 高（合同已签） | 法务负责人 |\n| 风险等级误判 | 执行时 | 业务方 | 中（影响决策） | 中（可补充条款） | 法务 + AI 产品 |\n| 格式错误 | 合同流转时 | 行政 | 低（可修正） | 低 | 行政 |\n| 法规引用过期 | 合规审查时 | 合规团队 | 高（合规风险） | 高 | 合规负责人 |\n\n**地图结论**：\n1. 关键条款遗漏和法规引用过期的后果最重，这两步必须保留人工确认\n2. 风险等级误判可以由 AI 先给建议，但需要附带依据供法务判断\n3. 格式错误可以让 AI 自动处理，风险低且易纠正\n\n**产品设计映射**：\n- 高后果步骤 → AI 给建议 + 人工确认 + 依据展示\n- 中后果步骤 → AI 执行 + 标注不确定 + 可修改\n- 低后果步骤 → AI 自动处理 + 日志记录 + 可回退\n\n## 示例 4：访谈问题设计——从\"喜不喜欢\"到\"哪一步不敢\"\n\n**场景**：为一个 AI 财务报告生成产品设计用户访谈问题。\n\n**低效问题**（得不到真实阻力）：\n- \"你觉得这个功能怎么样？\"\n- \"你会不会用？\"\n- \"你喜欢这个体验吗？\"\n\n**高效问题**（触及真实阻力）：\n- \"生成的报告你会直接用，还是会自己再算一遍？\"\n- \"哪一部分你最不放心交给它？\"\n- \"如果报告里有个数字错了，你最担心谁先发现？\"\n- \"老板问你这个数字怎么来的，你能解释吗？\"\n- \"如果系统在这里出错，你最不想承担什么后果？\"\n- \"你会把哪个步骤完全交给它？哪个步骤绝对不行？\"\n\n**访谈记录模板**：\n\n| 问题 | 用户回答 | 诊断 |\n|------|---------|------|\n| 哪部分最不放心？ | 收入预测那块 | 怕错——后果最重 |\n| 能解释数字来源吗？ | 有时候说不清 | 怕看不懂——缺乏依据 |\n| 会直接用吗？ | 不会，会再核一遍 | 怕担责——责任不清 |\n| 最不想承担什么？ | 数字被老板质疑 | 怕担责——责任链缺失 |\n\n## 四怕诊断详细框架\n\n### 怕错诊断\n**核心问题**：这个场景里最严重的错误是什么？\n**检查清单**：\n- [ ] 列出最严重的 3 种错误及其后果\n- [ ] 评估当前错误率是否可接受\n- [ ] 用户有没有低成本复核手段\n- [ ] 错误发现的时间窗口有多长\n- [ ] 错误一旦发生，纠正成本有多高\n\n**诊断输出**：如果错误后果重 + 发现晚 + 纠正难 + 无复核手段 = 用户一定怕错\n\n### 怕失控诊断\n**核心问题**：用户知不知道系统在做什么？\n**检查清单**：\n- [ ] 用户能看到系统正在执行什么吗\n- [ ] 用户能在任意点暂停或停止吗\n- [ ] 用户能修改或撤销结果吗\n- [ ] 高风险动作有没有确认点\n- [ ] 自动化边界是否清晰\n\n**诊断输出**：如果系统不透明 + 无暂停 + 无撤销 + 高风险无确认 = 用户一定怕失控\n\n### 怕担责诊断\n**核心问题**：出了问题最后谁来面对后果？\n**检查清单**：\n- [ ] 责任边界是否写清楚了\n- [ ] 用户知不知道自己在替系统承担什么\n- [ ] AI 给的建议是帮忙还是多了一层解释负担\n- [ ] 出了问题有没有清晰的回溯路径\n- [ ] 合规审查时能不能说清楚依据\n\n**诊断输出**：如果责任模糊 + 用户背锅 + 无回溯路径 = 用户一定怕担责\n\n### 怕看不懂诊断\n**核心问题**：用户能解释结果为什么这样吗？\n**检查清单**：\n- [ ] 结果附带推理依据吗\n- [ ] 来源是否可追溯\n- [ ] 不确定项是否有标记\n- [ ] 关键假设是否标注\n- [ ] 结果与原始输入是否可对照\n\n**诊断输出**：如果无依据 + 无来源 + 无不确定标记 = 用户一定怕看不懂\n\n## 阻力→设计需求转化矩阵\n\n| 阻力类型 | 用户行为信号 | 产品设计需求 | 设计示例 |\n|---------|------------|------------|---------|\n| 怕错 | 反复手动检查 | 校验机制 + 来源标注 | 不确定项标黄、来源可点击 |\n| 怕失控 | 手动备份/留台账 | 确认点 + 回退机制 | 暂停按钮、撤销操作、日志 |\n| 怕担责 | 不愿推荐给团队 | 责任边界清晰化 | 审批链、角色权限、责任声明 |\n| 怕看不懂 | 不用结果做决策 | 解释性 + 可追溯性 | 推理过程展示、来源引用 |\n| 怕错 + 怕担责 | 只用低风险场景 | 分级执行策略 | 低风险自动、高风险人工确认 |\n| 怕失控 + 怕看不懂 | 私下留人工台账 | 透明度 + 控制权 | 实时状态、可干预、可修改 |\n\n**使用说明**：先观察用户行为信号，判断主要阻力类型，再对应用设计需求。注意：多种阻力往往同时存在，需要综合设计。\n\n## 访谈问题库\n\n### 通用问题（适用所有场景）\n1. \"你会停在哪一步？\" —— 定位托付边界\n2. \"哪一步你绝不会交出去？\" —— 识别不可让渡的控制权\n3. \"如果它在这里出错，你最担心什么？\" —— 识别后果类型\n4. \"你最不想替它承担什么后果？\" —— 识别责任焦虑\n5. \"你会把它推荐给同事吗？为什么不会？\" —— 识别组织扩散障碍\n\n### 怕错场景专用\n6. \"这个结果你一般会检查几遍？\" —— 评估校验成本\n7. \"你上次发现它错是什么情况？\" —— 了解错误模式\n8. \"错了之后你怎么收场？\" —— 评估纠正成本\n\n### 怕担责场景专用\n9. \"如果老板问这个数字怎么来的，你怎么说？\" —— 评估解释能力\n10. \"出了问题谁来面对客户？\" —— 评估责任结构\n11. \"你会在什么情况下把它写进你的正式报告？\" —— 评估信任深度\n\n### 怕失控场景专用\n12. \"你能随时停下来吗？\" —— 评估控制感\n13. \"它做了你不知道的事，你会怎么办？\" —— 评估透明度\n14. \"你希望在哪些地方多一个确认？\" —— 识别确认需求\n\n## 阻力诊断流程图\n\n```\n用户不用 AI\n    │\n    ├─ 行为：试了几次就不用了\n    │   └─ 诊断：功能价值不足或体验摩擦大\n    │\n    ├─ 行为：用了但反复手动检查\n    │   └─ 诊断：怕错——校验成本高\n    │\n    ├─ 行为：只用低风险场景\n    │   └─ 诊断：怕错+怕担责——信任有边界\n    │\n    ├─ 行为：私下留人工台账\n    │   └─ 诊断：怕失控——托付结构没成立\n    │\n    ├─ 行为：不推荐给团队\n    │   └─ 诊断：怕担责——责任边界不清\n    │\n    └─ 行为：用了但从不拿结果做决策\n        └─ 诊断：怕看不懂——缺乏依据和可追溯性\n```\n\n## 采用阻力→产品改进优先级\n\n| 优先级 | 阻力类型 | 改进方向 | 预期效果 |\n|--------|---------|---------|---------|\n| P0 | 怕错（后果重+无法复核） | 校验机制+来源标注+风险提示 | 降低错误恐惧 |\n| P0 | 怕担责（责任完全在人） | 责任边界+审批链+角色权限 | 降低责任焦虑 |\n| P1 | 怕失控（无法干预） | 暂停/撤销/确认点 | 增加控制感 |\n| P1 | 怕看不懂（无依据） | 推理展示+来源引用 | 增加透明度 |\n| P2 | 综合阻力 | 先做托付梯度设计 | 渐进式信任 |\n\n**使用说明**：先诊断主要阻力类型，再按优先级改进。不要试图同时解决所有阻力——找到最重的那一层先突破。","tags":["p13j","organizational","judgment","native","product","agent","skills","gmaxxxie","agent-skills","ai-agent","ai-native","ai-product"],"capabilities":["skill","source-gmaxxxie","skill-p13j-organizational-judgment","topic-agent-skills","topic-ai-agent","topic-ai-native","topic-ai-product","topic-methodology","topic-product-management","topic-product-methodology","topic-product-thinking","topic-skills"],"categories":["ai-native-product-agent-skills"],"synonyms":[],"warnings":[],"endpointUrl":"https://skills.sh/gmaxxxie/ai-native-product-agent-skills/p13j-organizational-judgment","protocol":"skill","transport":"skills-sh","auth":{"type":"none","details":{"cli":"npx skills add gmaxxxie/ai-native-product-agent-skills","source_repo":"https://github.com/gmaxxxie/ai-native-product-agent-skills","install_from":"skills.sh"}},"qualityScore":"0.478","qualityRationale":"deterministic score 0.48 from registry signals: · indexed on github topic:agent-skills · 56 github stars · SKILL.md body (7,115 chars)","verified":false,"liveness":"unknown","lastLivenessCheck":null,"agentReviews":{"count":0,"score_avg":null,"cost_usd_avg":null,"success_rate":null,"latency_p50_ms":null,"narrative_summary":null,"summary_updated_at":null},"enrichmentModel":"deterministic:skill-github:v1","enrichmentVersion":1,"enrichedAt":"2026-05-18T18:57:30.653Z","embedding":null,"createdAt":"2026-05-01T01:02:57.430Z","updatedAt":"2026-05-18T18:57:30.653Z","lastSeenAt":"2026-05-18T18:57:30.653Z","tsv":"'1':30,60,85,160,261,280,335,347,372,476,674 '10':706 '11':709 '12':713 '13':716 '14':720 '2':33,83,92,196,277,284,352,374,381,479,677 '3':38,100,112,233,290,301,355,376,427,484,561,680 '4':47,107,131,296,311,363,378,506,684 '5':50,144,324,687 '6':692 '7':695 '8':698 '9':702 'ai':63,68,72,103,266,268,271,336,340,359,430,434,459,481,486,491,496,501,514,595,725 'decis':17 'hr':344,349,361 'judgment':4,19 'organiz':3 'outcom':20 'p0':762,770 'p1':777,784 'p13j':2 'p13j-organizational-judgment':1 'p2':790 'skill':8 'skill-p13j-organizational-judgment' 'source-gmaxxxie' 'structur':23 'team':16,22 'topic-agent-skills' 'topic-ai-agent' 'topic-ai-native' 'topic-ai-product' 'topic-methodology' 'topic-product-management' 'topic-product-methodology' 'topic-product-thinking' 'topic-skills' '一旦有人质疑筛选标准':357 '一旦这样问':127,205 '一笔带过':188 '万一错了客户会投诉':390 '不会':547 '不信':62 '不想用':67 '不想用ai':175 '不愿推荐给团队':639 '不推荐给团队':747 '不敢承担某种后果':65 '不是意见':171 '不用结果做决策':645 '不知道它怎么得出的':409 '不知道系统下一步会做什么':94 '不确定项是否有标记':610 '不确定项标记':392 '不确定项标黄':628 '不能笼统用':186 '不能轻易修改或撤销':95 '不要一句':415 '不要只理解成':147 '不要试图同时解决所有阻力':797 '不要问':327 '业务方':453 '个人判断无法形成组织能力':10 '中':454,456 '中后果步骤':495 '为一个':433,513 '为什么不会':689 '为什么使用率低':338 '为关键步骤画后果地图':252 '也要追问':149 '书稿第10章':173,209,242 '了事':417 '了解错误模式':697 '产品':460 '产品才有机会真正对症':82,180 '产品改进优先级':757 '产品设计映射':489 '产品设计需求':388,622 '产品设计需求映射':383 '人工确认':493 '从':508 '从能力角度看表现不差':342 '他只是很清楚':73,164 '他是不是怕发错对象':150 '以':429 '优先级':758 '会再核一遍':548 '会直接用吗':546 '会看':270 '会让':265 '但托付结构并没有成立':275 '但推到用人经理和':343 '但需要附带依据供法务判断':483 '低':464,466 '低后果步骤':500 '低效问题':516 '低风险自动':654 '你上次发现它错是什么情况':696 '你会不会用':119,211,519 '你会停在哪一步':122,202,214,330,675 '你会在什么情况下把它写进你的正式报告':710 '你会怎么办':718 '你会把哪个步骤完全交给它':532 '你会把它推荐给同事吗':688 '你喜不喜欢':328 '你喜欢这个体验吗':520 '你希望在哪些地方多一个确认':721 '你怎么说':704 '你最不想承担什么后果':531 '你最不想替它承担什么后果':126,216,333,685 '你最担心什么':682 '你最担心谁先发现':527 '你能解释吗':529 '你能随时停下来吗':714 '你觉得这个功能怎么样':118,210,518 '使用说明':664,794 '依据':419 '依据展示':494 '依据是什么':110 '信任有边界':740 '停':230 '停止':289 '允许用人经理调整权重和标准':375 '先不要猜':191 '先做托付梯度设计':792 '先给建议':482 '先观察用户行为信号':665 '先诊断主要阻力类型':795 '公司':445 '关键假设是否标注':611 '关键假设标注':413 '关键条款遗漏':443 '关键条款遗漏和法规引用过期的后果最重':477 '关键步骤人工确认':394 '关键步骤分析':436 '其实很多时候不是':70,177 '典型表现':387 '再对应用设计需求':667 '再按优先级改进':796 '决策仪式设计':39 '决策会议模板':27 '决策结果与预期对比':21 '出了事谁来背':402 '出了问题最后谁来面对后果':591 '出了问题最后谁来面对客户':292 '出了问题有没有清晰的回溯路径':597 '出了问题谁来面对客户':707 '出问题时有清晰的回溯路径':379 '分步执行':259 '分级执行策略':653 '列出最严重的':560 '判断主要阻力类型':666 '判断显性化':31 '判断沉淀是长期过程':57 '判断沉淀机制设计':28 '别问':113,197 '到':510 '功能价值不足或体验摩擦大':729 '功能问题解决的是':154 '动作日志':397 '协作链':142,246 '原则沉淀':51 '反复手动检查':625 '发现晚':570 '发送':269 '变成可以拆':423 '只有把风险感知拆开':81,179 '只用低风险场景':652,736 '可以改':424 '可以设计的产品结构':425 '可修改':499,663 '可修正':465 '可回退':504 '可干预':662 '可撤销':399 '可暂停':398 '可能损失权益':447 '可补充条款':457 '可解释的筛选依据':373 '可追溯性':647 '合同审查为例':431 '合同审查产品绘制错误后果地图':435 '合同已签':449 '合同流转时':462 '合规团队':470 '合规审查':294 '合规审查时':469 '合规审查时能不能说清楚依据':598 '合规负责人':474 '合规风险':472 '后果中等的可以让ai先给建议但需要附带依据':249 '后果会不会扩散':255,306 '后果会停在这里还是继续扩散':136,239 '后果很实际':351 '后果扩散性':440 '后果最重':541 '后果最重的步骤必须保留人工确认':248 '后果轻的可以让ai自动处理':250 '后果重':764 '后果链紧紧连在一起':143,247 '后者的诊断往往比前者更接近采用卡点的真实原因':158 '和用人经理':362 '哪一步不敢':116,200,227,511 '哪一步你会想再确认一下':123,203 '哪一步你绝不会交出去':124,204,331,678 '哪一部分你最不放心交给它':525 '哪个步骤绝对不行':533 '哪些异常升级':407 '哪些必须人工确认':406 '哪些是建议':404 '哪些自动做':405 '哪部分最不放心':538 '喜不喜欢':114,198,225,509 '嘴上说还不错但行为上一直绕过你':264 '四怕诊断':278,346 '四怕诊断详细框架':555 '回退':421 '回退机制':634 '团队决策流程与角色':24 '团队决策质量不稳定':11 '团队重要决策记录':18 '地图结论':475 '场景':339,384,432,512 '增加控制感':783 '增加透明度':789 '复盘机制':48 '外部顾问':37 '多元化输入':34 '多种阻力往往同时存在':669 '失控':75,166 '如':41 '如果':102 '如果它出错你最担心什么':332 '如果它在这里出错':681 '如果它在这里出错你最担心什么':125,215 '如果报告里有个数字错了':526 '如果无依据':614 '如果系统不透明':584 '如果系统只给一个分数却不给可解释依据':365 '如果系统在这里出错':530 '如果老板问这个数字怎么来的':703 '如果责任模糊':600 '如果这一步做错':74,165 '如果错了谁先发现':438 '如果错误后果重':569 '字段':14 '它做了你不知道的事':717 '它做了我不知道的事':396 '它能不能做':155 '它说明表层功能可能成立了':274 '定位托付边界':676 '定期对照结果回溯判断质量':49 '实时状态':661 '审批链':641,774 '审查步骤':437 '对每个采用率低的ai功能':190 '将个人判断转化为团队判断能力的系统方法':6 '将有效的判断经验抽象为团队原则':52 '就会变成可以诊断的问题':130,208 '就能解决的':370 '就默认是观念问题或对新技术的天然保守':69,176 '工作流程':29 '应用':189,222,251 '建立信任':187,416 '引入反对者':36 '影响决策':455 '很多':128,206 '很多团队一听到用户说':66,174 '很多采用阻力一画这张图就会突然清楚':139 '很多采用阻力一画错误后果地图就会突然清楚':243 '得不到真实阻力':517 '心理阻力':382,386 '心理阻力问题解决的是':156 '怕发出去之后要自己解释':153 '怕口气不对':151 '怕失控':93,182,285,317,353,395,630,656,744,778 '怕失控场景专用':712 '怕失控诊断':574 '怕承诺过头':152 '怕担责':101,183,291,319,356,401,549,553,638,651,739,749,771 '怕担责场景专用':701 '怕担责诊断':589 '怕看不懂':108,184,297,321,364,408,544,644,657,754,785 '怕看不懂诊断':604 '怕错':86,181,281,315,348,389,540,624,650,733,738,763 '怕错场景专用':691 '怕错诊断':556 '怕错过合适候选人':350 '总结但不会拿它做会议结论':272 '想建立可持续的判断沉淀机制':12 '或者最后要我来背锅':77,168 '手动备份':631 '手里时使用率很低':345 '托付结构没成立':745 '执行':497 '执行时':452 '找到最重的那一层先突破':798 '把功能问题翻译成心理阻力问题':145 '把常见心理阻力映射到具体设计需求':385 '把所有':224 '把诊断出的心理阻力转化为具体的产品设计需求':314 '招聘初筛助手':337 '招聘初筛助手可根据岗位要求和简历内容给出候选人优先级建议':341 '控制':420 '控制权':660 '推理依据展示':410 '推理展示':787 '推理过程展示':648 '撤销':288,781 '撤销操作':636 '收入预测那块':539 '改进方向':760 '数字被老板质疑':552 '无不确定标记':616 '无依据':786 '无回溯路径':602 '无复核手段':572 '无撤销':586 '无暂停':585 '无来源':615 '无法复核':765 '无法干预':779 '日志':637 '日志记录':503 '明确哪些判断是建议哪些必须人工确认':377 '暂停':780 '暂停按钮':635 '更有效的问法':121,201 '最不想承担什么':551 '最后落到谁身上':221 '最后谁来解释':138,241,257,308 '最后谁解释':442 '最后需要解释的人不是':358 '有时候说不清':543 '来源可点击':629 '来源引用':411,649,788 '来源是否可追溯':609 '来源标注':391,627,767 '标注不确定':498 '校验成本高':734 '校验机制':626,766 '核心概念':59 '核心问题':557,575,590,605 '格式错误':461 '格式错误可以让':485 '检查清单':559,577,592,607 '模型不够强':192 '模型还要再强一点':369 '模糊不放心':129,207 '步骤':260,276,300,310,323 '比功能优化更有用的诊断工具':235 '民主投票':55 '没人愿意真的依赖它':366 '法务':458 '法务审核时':444 '法务负责人':450 '法规引用过期':468 '注意':668 '注意事项':53 '深入核心概念':159 '渐进式信任':793 '然后把心理阻力转化为具体设计需求':195 '生成的报告你会直接用':523 '生成质量还不够高':148 '用了但从不拿结果做决策':752 '用了但反复手动检查':731 '用人经理不想让系统把人选节奏带偏':354 '用户一定怕失控':588 '用户一定怕担责':603 '用户一定怕看不懂':617 '用户一定怕错':573 '用户不是在抽象评估技术':218 '用户不用':724 '用户不用自动生成邮件':146 '用户为什么不敢交':157 '用户关注的不是平均表现而是最糟时刻能不能收住':91 '用户只是在评估具体后果':178 '用户四怕':84 '用户回答':536 '用户并不是抽象地排斥':71 '用户并不是抽象地排斥ai':163 '用户怕的不是自动化本身':98 '用户有没有低成本复核手段':283,564 '用户没有低成本复核手段':90 '用户的害怕不是空穴来风':140,244 '用户知不知道系统在做什么':286,576 '用户知不知道自己在替系统承担什么':594 '用户背锅':601 '用户能不能轻易纠正':137,240 '用户能修改或撤销结果吗':580 '用户能在任意点暂停或停止吗':579 '用户能看到系统正在执行什么吗':578 '用户能解释结果为什么这样吗':298,606 '用户行为信号':621 '用这张图决定ai在每一步的进入策略':258 '画一张最朴素的地图':133,236 '画出关键步骤的后果地图':303 '留台账':632 '的位置':231 '看不懂会让人失去判断自己该不该信的能力':111 '真正需要的是':371 '确保决策集合了不同视角':35 '确认点':633,782 '示例':334,380,426,505 '私下留人工台账':658,742 '种错误及其后果':562 '类问题':228 '类问题改写成':226 '系统把太多决定打包自动完成':97 '系统有没有给依据和来源':299 '纠正成本有多高':567 '纠正难':571 '纠正难度':441 '组织判断':54 '组织判断checklist':26 '组织判断力':5,7 '结果一旦错会影响客户':87 '结果与原始输入对照':412 '结果与原始输入是否可对照':612 '结果为什么这样':109 '结果附带推理依据吗':608 '结论':367 '给建议':492 '给建议但最后还要我签字':104 '给的建议是帮忙还是多了一层解释负担':596 '综合阻力':791 '缺乏依据':545 '缺乏依据和可追溯性':755 '老板':293 '老板问你这个数字怎么来的':528 '而':213 '而是':64,360 '而是做四怕诊断':193 '而是和真实责任链':141,245 '而是在评估':219 '而是自己被排除在控制链之外':99 '而是风险感知':80,162,172 '而要把信任需要的条件':418 '能不能修改':287 '能不能纠正':256,307 '能解释数字来源吗':542 '自动化边界是否清晰':582 '自动化边界设置':400 '自动处理':487,502 '行为':726,730,735,741,746,751 '行政':463,467 '表决':45 '要明确决策责任人':56 '要求团队在决策时明确记录判断依据与置信度':32 '要问':115,199,329 '观察用户的实际行为':263 '角色权限':642,775 '解释性':646 '触及真实阻力':522 '讨论':44 '记录':46 '记录每个':229 '设计原则':414 '设计用户访谈时':223 '设计示例':623 '设计结构化的决策会议流程':40 '设计能触及真实阻力的访谈问题':326 '设计需求转化':313 '设计需求转化矩阵':619 '访谈中最有效的转法':117 '访谈记录模板':534 '访谈问题库':671 '访谈问题设计':325,507 '评估信任深度':711 '评估当前错误率是否可接受':563 '评估控制感':715 '评估校验成本':694 '评估纠正成本':700 '评估解释能力':705 '评估责任结构':708 '评估透明度':719 '识别不可让渡的控制权':679 '识别后果类型':683 '识别确认需求':722 '识别组织扩散障碍':690 '识别责任焦虑':686 '诊断':537,728,732,737,743,748,753 '诊断输出':568,583,599,613 '试了几次就不用了':727 '说不清':76,167 '说明':15 '谁先受影响':135,238,254,305,439 '财务报告生成产品设计用户访谈问题':515 '责任':422 '责任不清':550 '责任声明':643 '责任完全在人':772 '责任感知常常比能力表现更直接影响采用':106 '责任边界':773 '责任边界不清':750 '责任边界是否写清楚了':593 '责任边界清不清楚':295 '责任边界清晰化':403,640 '责任链缺失':554 '起草但不会让':267 '输入':13 '输出':25 '还是会自己再算一遍':524 '这一步如果错了谁先发现':134,237 '这两步必须保留人工确认':478 '这个场景里最严重的错误是什么':282,558 '这个结果你一般会检查几遍':693 '这些问法会把模糊态度变成具体诊断点':217 '这些问题很难触及真正阻力':120,212 '这件事出了问题':220 '这四种恐惧各自对应不同的产品设计需求':185 '这建议是帮我还是多一个我得解释的东西':105 '这张图会帮助你理解用户为什么在某些步骤上特别保守':309 '这类静默绕过比抱怨更值得警惕':273 '适用场景':9 '适用所有场景':673 '透明度':659 '逐项检查':279 '逐项检查用户到底在怕什么':194 '通用问题':672 '那就是托付边界所在':232 '那我为什么要把它交出去':78,169 '采用阻力':756 '采用阻力不是':61 '采用阻力的底层':170 '采用阻力的底层不是意见':79,161 '采用阻力识别':262 '错了之后你怎么收场':699 '错了谁先发现':253,304 '错误一旦发生':566 '错误会扩散到后续流程':89 '错误发现的时间窗口有多长':565 '错误后果地图':132,234,428 '错误后果地图绘制':302 '错误很难被及时发现':88 '问题':535 '问题不是一句':368 '阻力':312,618 '阻力类型':620,759 '阻力诊断流程图':723 '降低责任焦虑':776 '降低错误恐惧':769 '需要持续记录与复盘':58 '需要校验机制和来源标注':316 '需要确认点和回退机制':318 '需要综合设计':670 '需要解释性和可追溯性':322 '需要责任边界清晰化':320 '预期效果':761 '预读':43 '预读-讨论-表决-记录':42 '风险低且易纠正':488 '风险句高亮':393 '风险提示':768 '风险等级误判':451 '风险等级误判可以由':480 '高':446,448,471,473 '高后果步骤':490 '高效问题':521 '高风险人工确认':655 '高风险动作有没有确认点':581 '高风险动作没有确认点':96 '高风险无确认':587","prices":[{"id":"7bc24434-4400-4cc6-b674-7a4780799971","listingId":"f632f8ed-b1c3-41df-842f-566916bb0b9e","amountUsd":"0","unit":"free","nativeCurrency":null,"nativeAmount":null,"chain":null,"payTo":null,"paymentMethod":"skill-free","isPrimary":true,"details":{"org":"gmaxxxie","category":"ai-native-product-agent-skills","install_from":"skills.sh"},"createdAt":"2026-05-01T01:02:57.430Z"}],"sources":[{"listingId":"f632f8ed-b1c3-41df-842f-566916bb0b9e","source":"github","sourceId":"gmaxxxie/ai-native-product-agent-skills/p13j-organizational-judgment","sourceUrl":"https://github.com/gmaxxxie/ai-native-product-agent-skills/tree/main/skills/p13j-organizational-judgment","isPrimary":false,"firstSeenAt":"2026-05-01T01:02:57.430Z","lastSeenAt":"2026-05-18T18:57:30.653Z"}],"details":{"listingId":"f632f8ed-b1c3-41df-842f-566916bb0b9e","quickStartSnippet":null,"exampleRequest":null,"exampleResponse":null,"schema":null,"openapiUrl":null,"agentsTxtUrl":null,"citations":[],"useCases":[],"bestFor":[],"notFor":[],"kindDetails":{"org":"gmaxxxie","slug":"p13j-organizational-judgment","github":{"repo":"gmaxxxie/ai-native-product-agent-skills","stars":56,"topics":["agent-skills","ai-agent","ai-native","ai-product","methodology","product-management","product-methodology","product-thinking","skills"],"license":null,"html_url":"https://github.com/gmaxxxie/ai-native-product-agent-skills","pushed_at":"2026-05-06T07:19:36Z","description":"AI Native Product Methodology — 80 executable skills across P0-P14 stages, covering needs discovery to aesthetic authority. From 8 books.","skill_md_sha":"9283cc3357bcf282187b7db4436f597e0eaf74a9","skill_md_path":"skills/p13j-organizational-judgment/SKILL.md","default_branch":"main","skill_tree_url":"https://github.com/gmaxxxie/ai-native-product-agent-skills/tree/main/skills/p13j-organizational-judgment"},"layout":"multi","source":"github","category":"ai-native-product-agent-skills","frontmatter":{"name":"p13j-organizational-judgment","description":"组织判断力——将个人判断转化为团队判断能力的系统方法"},"skills_sh_url":"https://skills.sh/gmaxxxie/ai-native-product-agent-skills/p13j-organizational-judgment"},"updatedAt":"2026-05-18T18:57:30.653Z"}}