1. 从「读过就忘」到「评审必查」67 个 UX 认知偏差的工程化困境《认知偏差知识手册》这类资料有个共同特点第一次读很爽第二次找很累。飞书设计团队整理的这份手册覆盖了 67 个常见认知偏差做市场、做设计、做用户研究的人都能从中找到对应条目。但真正落到产品评审会上问题就来了——你记得「锚定效应」大概是什么意思却想不起它对应的设计建议是什么你知道某个交互「感觉不对」但说不清踩中了哪条偏差。我试过把手册内容复制到本地 Markdown结果三个月后文件躺在某个文件夹里再也没打开过。原因很简单阅读材料和检查清单是两种东西。阅读材料追求叙事流畅检查清单追求字段结构化、可检索、可批量调用。前者靠人脑记忆后者靠工程手段。这篇要解决的问题很具体把 67 个认知偏差从「文档里的段落」变成「可检索的决策清单」并且用统一 Key 通道做一次批量调用验证让清单不只是静态表格而是能在评审现场被快速查询、被脚本批量处理的活数据。适合谁看产品经理、交互设计师、用户研究员以及任何需要在评审会上快速引用认知偏差依据的人。你不需要会写复杂代码但需要能复制粘贴命令、能改 JSON 字段。整篇的节奏是先给清单字段模板再给检索脚本最后用 TaoToken 统一 Key 做一次批量调用验证确认清单能被程序化消费。核心检索词先明确认知偏差知识手册 67 个常见认知偏差 可检索决策清单。这三个词贯穿全文后面所有步骤都围绕它们展开。先说清楚一个前提认知偏差不是「用户笨」而是人脑在信息过载时的默认捷径。手册里 67 条偏差本质上是对这些捷径的命名。命名的价值在于——评审时你说「这里用户会默认选中间选项」不如说「这里踩中了默认效应Default Effect建议把推荐项前置并标注理由」。后者可追溯、可讨论、可验证。所以工程化的第一步不是写代码而是定义字段。字段定义错了后面检索和调用都是白费。下一节先给字段模板再讲怎么把手册条目填进去。2. TaoToken 统一 Key 前置准备为什么清单需要一条调用通道你可能会问一个认知偏差清单为什么需要 API Key直接存成 Excel 不就行了Excel 能解决「人查」解决不了「批量验证」和「跨工具复用」。举个实际场景评审前你想让脚本自动检查清单里每条偏差是否都有对应的设计建议字段缺字段的条目自动标红或者你想把清单接入内部评审系统让每条偏差能按关键词返回结构化结果。这些都需要程序化调用通道。TaoToken 在这里的角色是统一 Key 通道。它的价值不是「多一个 API」而是把模型调用收敛到一个 Base URL 和一把 Key 上清单脚本不用为不同模型维护多套配置。官网入口在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api 这个不加 UTM直接用于代码里的 Base URL。前置准备分三步都不复杂第一步拿到 Key。进入控制台创建 API Key路径是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 在 API Keys 页面生成。生成的 Key 形如sk-开头的一串字符复制后先存到环境变量里别直接写进脚本。第二步确认模型 ID。清单检索脚本不需要最强模型选一个响应快、成本低的即可。模型对话页面在 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 可以在这里试跑一条偏差查询确认返回格式符合预期。第三步确认接入文档。不同语言的调用示例在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 重点看 Base URL 和鉴权头的写法。文档里会明确Authorization: Bearer 你的Key这种格式。这里有个容易踩的坑很多人把 Base URL 写成https://taotoken.net而不是https://taotoken.net/api结果请求 404。记住代码里的 Base URL 必须带/api官网首页地址是给人看的API 地址是给程序用的两者不要混。如果你后续要做长期编码或 Agent 类任务可以了解 Coding Plan入口在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。但本篇的清单验证用普通 API Key 就够了不需要额外套餐。前置准备完成后你手里应该有三样东西一把 Key、一个模型 ID、一个确认过的 Base URL。下一节开始写清单字段模板和可复制配置。3. 可复制配置清单字段模板与检索脚本 settings 片段这一节给两样东西清单的字段模板JSON 结构以及检索脚本的配置片段含 Base URL、Key、Model ID 三件套。路径和原文一致直接复制改 Key 就能跑。先定义清单字段。67 条偏差每条至少包含以下字段缺一个都会影响后续检索和评审引用{ id: CB-001, name_cn: 锚定效应, name_en: Anchoring Effect, category: 决策与判断, definition: 人们过度依赖最先接触到的信息锚点来做后续判断。, ux_symptom: 价格页先展示高价套餐后续套餐显得便宜。, design_check: 检查是否存在无依据的初始锚点锚点是否对用户有利。, review_question: 这个页面第一个出现的数字/选项是否在无意中设定了用户预期, severity: 高, source: 认知偏差知识手册 }字段说明用表格对照更清楚字段作用评审时的用法id唯一标识评审记录里引用「CB-001」而非「那个锚定啥的」name_cn / name_en中英文名检索时中英都能命中category分类按类别批量走查比如只看「决策与判断」类definition定义新人快速理解不用翻原手册ux_symptomUX 症状评审时对照当前设计找相似症状design_check设计检查项直接作为走查清单条目review_question评审提问会上直接念出来引导讨论severity严重度决定是否阻塞上线把 67 条按这个结构填完存成cognitive_bias_checklist.json。填的时候注意ux_symptom和design_check要写具体别写「注意锚定效应」这种废话要写「价格页首个套餐是否为最高价」这种可判断的句子。接下来是检索脚本的配置片段。用 Python 举例先装依赖pip install openai然后写配置文件settings.toml把三件套放进去[taotoken] base_url https://taotoken.net/api api_key sk-你的Key替换这里 model_id 你的模型ID [checklist] path ./cognitive_bias_checklist.json top_k 3注意base_url结尾不带斜杠api_key从环境变量读更安全这里为了演示直接写。实际用时建议改成api_key ${TAOTOKEN_API_KEY}并在运行前 export。检索脚本核心逻辑读清单、按关键词匹配、把匹配到的条目拼成 prompt、调用 TaoToken 返回结构化建议。关键代码片段import json, tomllib from openai import OpenAI with open(settings.toml, rb) as f: cfg tomllib.load(f) client OpenAI( base_urlcfg[taotoken][base_url], api_keycfg[taotoken][api_key], ) with open(cfg[checklist][path], encodingutf-8) as f: checklist json.load(f) def search_bias(keyword): hits [b for b in checklist if keyword in b[name_cn] or keyword in b[name_en] or keyword in b[ux_symptom]] return hits[:cfg[checklist][top_k]] def ask_bias(keyword): hits search_bias(keyword) context \n.join( f{b[id]} {b[name_cn]}: {b[design_check]} for b in hits ) resp client.chat.completions.create( modelcfg[taotoken][model_id], messages[ {role: system, content: 你是UX评审助手基于给定偏差条目回答。}, {role: user, content: f关键词{keyword}\n相关条目\n{context}\n请给出评审建议。}, ], ) return resp.choices[0].message.content print(ask_bias(价格))这段代码里base_url、api_key、model_id三件套齐全路径与 settings.toml 一致。跑之前确认cognitive_bias_checklist.json和脚本在同一目录。如果你用 Cline 或类似工具做 MCP 接入配置里同样要写全三件套。以 Cline 的 MCP 配置为例{ mcpServers: { taotoken-bias: { command: python, args: [bias_server.py], env: { TAOTOKEN_BASE_URL: https://taotoken.net/api, TAOTOKEN_API_KEY: sk-你的Key, TAOTOKEN_MODEL_ID: 你的模型ID } } } }三件套一个都不能少。少 Base URL 会连到默认地址少 Key 会 401少 Model ID 会报模型不存在。下一节验证请求看实际返回。4. 验证请求与成功结果一次批量调用确认清单可消费配置写完后先做单条验证再做批量验证。单条验证确认通道通批量验证确认清单能被程序化消费。单条验证直接跑上一节的ask_bias(价格)。预期返回类似根据 CB-001 锚定效应和 CB-012 损失厌恶价格页评审建议 1. 检查首个展示套餐是否为最高价若是确认是否有意为之 2. 折扣信息是否强调「省了多少」而非「原价多少」 3. 限时优惠是否制造了不必要的时间压力。如果返回这种结构化建议说明通道通了。如果返回报错对照下一节的排查表。批量验证写一个循环把 67 条偏差的review_question逐条发给模型检查每条是否都能返回非空结果import json from openai import OpenAI client OpenAI(base_urlhttps://taotoken.net/api, api_keysk-你的Key) with open(cognitive_bias_checklist.json, encodingutf-8) as f: checklist json.load(f) failed [] for b in checklist: try: resp client.chat.completions.create( model你的模型ID, messages[{role: user, content: b[review_question]}], max_tokens200, ) text resp.choices[0].message.content if not text or len(text) 10: failed.append((b[id], 空返回)) except Exception as e: failed.append((b[id], str(e))) print(f总数 {len(checklist)}失败 {len(failed)}) for fid, reason in failed: print(fid, reason)成功结果应该是总数 67失败 0。如果有失败看下一节。批量验证的意义不只是「确认能调通」而是确认清单的review_question字段质量。如果某条偏差的提问太模糊模型返回也会模糊这种条目在评审会上同样不好用。批量跑一遍等于对清单做了一次质量体检。实测下来67 条里通常有 3 到 5 条需要改写review_question原因是提问里带了「是否」「有没有」这种封闭式问法模型容易只回「是」或「否」。改成开放式比如把「是否有锚点」改成「这个页面第一个出现的数字是什么它如何影响用户对后续价格的判断」返回质量会明显提升。验证通过后清单就可以接入评审流程了。最简单的用法评审前把当前设计稿的关键词比如「价格」「注册」「弹窗」跑一遍检索把命中的偏差条目打印出来会上逐条对照。进阶用法把检索脚本包成内部工具评审时实时查询。下一节处理验证过程中可能遇到的报错。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth验证阶段最常见的四类报错逐个说清楚原因和解法。401 Unauthorized。返回体通常是{error: {message: Invalid API key}}。原因有三个Key 复制时带了空格、Key 已失效、鉴权头格式写错。检查顺序先确认api_key字段没有首尾空格再确认 Key 在控制台里是启用状态最后确认代码里是Authorization: Bearer sk-xxx而不是Authorization: sk-xxx。如果用的是环境变量确认 export 的变量名和代码里读的一致。local proxy failed。这个报错通常出现在本地脚本通过某些工具转发请求时。原因是你本地配置了转发规则但转发目标不可达。解法检查脚本里的base_url是否直接写成https://taotoken.net/api不要经过本地中间层。如果你在用 Cline 或类似工具检查 MCP 配置里的TAOTOKEN_BASE_URL是否被其他环境变量覆盖。最稳妥的做法是在脚本开头打印一次实际使用的 base_url确认它就是你写的那个。reading choices 相关报错。典型信息是AttributeError: NoneType object has no attribute choices或KeyError: choices。这说明响应体里没有choices字段通常是请求根本没成功返回的是错误 JSON。解法在调用后先打印resp原始内容看它到底是成功响应还是错误响应。如果错误信息里有model not found说明 Model ID 写错了去模型对话页面确认正确的 ID。如果错误信息里有max_tokens相关说明参数超限调小即可。OAuth 相关报错。如果你在 Claude Code 或类似工具里配置可能遇到 OAuth 流程报错。这类工具通常要求填 Base URL、Key、Model ID 三件套而不是走 OAuth。检查你的配置里是否误开了 OAuth 模式。以 Claude Code 为例配置应写成{ baseUrl: https://taotoken.net/api, apiKey: sk-你的Key, model: 你的模型ID }三件套齐全不要留空。如果工具提示 OAuth说明它没读到你的 Key 配置检查配置文件路径是否正确。另外两个容易忽略的点一是 JSON 清单文件编码必须用 UTF-8否则中文条目会乱码导致检索失败二是top_k设太大比如设成 10prompt 会很长返回变慢且容易截断建议 3 到 5。排查完这些批量验证应该能跑到失败 0。最后说下清单的日常维护和 CTA 分流。6. 清单维护与调用通道选择把 67 条偏差变成团队资产清单建好后维护比创建更重要。三个实用建议第一给每条偏差加last_reviewed字段记录上次在评审中被引用的日期。半年没被引用的条目要么是分类太偏要么是提问写得不好值得回头改。第二把severity字段和评审流程绑定。高严重度条目在评审时必须逐条确认中低严重度可以抽样。这样清单不只是查询工具而是评审节奏的一部分。第三定期用批量脚本跑一遍全量检查返回质量。模型更新后同样的review_question可能返回不同风格的建议跑一遍能及时发现。调用通道的选择上分三种情况如果只是偶尔查几条偏差用模型对话页面手动查最快入口在 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 如果要把检索脚本接入内部工具用 API Key在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 管理 Key接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 如果要做长期的评审 Agent让它自动跑清单、自动生成评审报告可以了解 Coding Plan入口在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。最后回到清单本身。67 个认知偏差真正高频出现在评审里的可能只有 15 到 20 个。但这不代表其余条目没用——它们的价值在于当评审陷入「我觉得这样不好」的僵局时你能从清单里找到一条命名的偏差把主观感受变成可讨论的客观条目。这才是「可检索决策清单」的真正意义不是替代判断而是给判断提供可追溯的依据。清单文件建议放团队共享仓库脚本和 settings.toml 一起提交Key 用环境变量注入不要提交。这样新人入职拉下来就能跑评审时随时查。从阅读材料到团队资产差的不是工具是字段和通道这两步工程化动作。 
长河君 · 2026/10/8 12:33:36 · 阅读 1.2k 认知偏差知识手册：用 TaoToken 统一 Key 把 67 个 UX 偏差做成可检索的决策清单
1. 从「读过就忘」到「评审必查」67 个 UX 认知偏差的工程化困境《认知偏差知识手册》这类资料有个共同特点第一次读很爽第二次找很累。飞书设计团队整理的这份手册覆盖了 67 个常见认知偏差做市场、做设计、做用户研究的人都能从中找到对应条目。但真正落到产品评审会上问题就来了——你记得「锚定效应」大概是什么意思却想不起它对应的设计建议是什么你知道某个交互「感觉不对」但说不清踩中了哪条偏差。我试过把手册内容复制到本地 Markdown结果三个月后文件躺在某个文件夹里再也没打开过。原因很简单阅读材料和检查清单是两种东西。阅读材料追求叙事流畅检查清单追求字段结构化、可检索、可批量调用。前者靠人脑记忆后者靠工程手段。这篇要解决的问题很具体把 67 个认知偏差从「文档里的段落」变成「可检索的决策清单」并且用统一 Key 通道做一次批量调用验证让清单不只是静态表格而是能在评审现场被快速查询、被脚本批量处理的活数据。适合谁看产品经理、交互设计师、用户研究员以及任何需要在评审会上快速引用认知偏差依据的人。你不需要会写复杂代码但需要能复制粘贴命令、能改 JSON 字段。整篇的节奏是先给清单字段模板再给检索脚本最后用 TaoToken 统一 Key 做一次批量调用验证确认清单能被程序化消费。核心检索词先明确认知偏差知识手册 67 个常见认知偏差 可检索决策清单。这三个词贯穿全文后面所有步骤都围绕它们展开。先说清楚一个前提认知偏差不是「用户笨」而是人脑在信息过载时的默认捷径。手册里 67 条偏差本质上是对这些捷径的命名。命名的价值在于——评审时你说「这里用户会默认选中间选项」不如说「这里踩中了默认效应Default Effect建议把推荐项前置并标注理由」。后者可追溯、可讨论、可验证。所以工程化的第一步不是写代码而是定义字段。字段定义错了后面检索和调用都是白费。下一节先给字段模板再讲怎么把手册条目填进去。2. TaoToken 统一 Key 前置准备为什么清单需要一条调用通道你可能会问一个认知偏差清单为什么需要 API Key直接存成 Excel 不就行了Excel 能解决「人查」解决不了「批量验证」和「跨工具复用」。举个实际场景评审前你想让脚本自动检查清单里每条偏差是否都有对应的设计建议字段缺字段的条目自动标红或者你想把清单接入内部评审系统让每条偏差能按关键词返回结构化结果。这些都需要程序化调用通道。TaoToken 在这里的角色是统一 Key 通道。它的价值不是「多一个 API」而是把模型调用收敛到一个 Base URL 和一把 Key 上清单脚本不用为不同模型维护多套配置。官网入口在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api 这个不加 UTM直接用于代码里的 Base URL。前置准备分三步都不复杂第一步拿到 Key。进入控制台创建 API Key路径是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 在 API Keys 页面生成。生成的 Key 形如sk-开头的一串字符复制后先存到环境变量里别直接写进脚本。第二步确认模型 ID。清单检索脚本不需要最强模型选一个响应快、成本低的即可。模型对话页面在 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 可以在这里试跑一条偏差查询确认返回格式符合预期。第三步确认接入文档。不同语言的调用示例在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 重点看 Base URL 和鉴权头的写法。文档里会明确Authorization: Bearer 你的Key这种格式。这里有个容易踩的坑很多人把 Base URL 写成https://taotoken.net而不是https://taotoken.net/api结果请求 404。记住代码里的 Base URL 必须带/api官网首页地址是给人看的API 地址是给程序用的两者不要混。如果你后续要做长期编码或 Agent 类任务可以了解 Coding Plan入口在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。但本篇的清单验证用普通 API Key 就够了不需要额外套餐。前置准备完成后你手里应该有三样东西一把 Key、一个模型 ID、一个确认过的 Base URL。下一节开始写清单字段模板和可复制配置。3. 可复制配置清单字段模板与检索脚本 settings 片段这一节给两样东西清单的字段模板JSON 结构以及检索脚本的配置片段含 Base URL、Key、Model ID 三件套。路径和原文一致直接复制改 Key 就能跑。先定义清单字段。67 条偏差每条至少包含以下字段缺一个都会影响后续检索和评审引用{ id: CB-001, name_cn: 锚定效应, name_en: Anchoring Effect, category: 决策与判断, definition: 人们过度依赖最先接触到的信息锚点来做后续判断。, ux_symptom: 价格页先展示高价套餐后续套餐显得便宜。, design_check: 检查是否存在无依据的初始锚点锚点是否对用户有利。, review_question: 这个页面第一个出现的数字/选项是否在无意中设定了用户预期, severity: 高, source: 认知偏差知识手册 }字段说明用表格对照更清楚字段作用评审时的用法id唯一标识评审记录里引用「CB-001」而非「那个锚定啥的」name_cn / name_en中英文名检索时中英都能命中category分类按类别批量走查比如只看「决策与判断」类definition定义新人快速理解不用翻原手册ux_symptomUX 症状评审时对照当前设计找相似症状design_check设计检查项直接作为走查清单条目review_question评审提问会上直接念出来引导讨论severity严重度决定是否阻塞上线把 67 条按这个结构填完存成cognitive_bias_checklist.json。填的时候注意ux_symptom和design_check要写具体别写「注意锚定效应」这种废话要写「价格页首个套餐是否为最高价」这种可判断的句子。接下来是检索脚本的配置片段。用 Python 举例先装依赖pip install openai然后写配置文件settings.toml把三件套放进去[taotoken] base_url https://taotoken.net/api api_key sk-你的Key替换这里 model_id 你的模型ID [checklist] path ./cognitive_bias_checklist.json top_k 3注意base_url结尾不带斜杠api_key从环境变量读更安全这里为了演示直接写。实际用时建议改成api_key ${TAOTOKEN_API_KEY}并在运行前 export。检索脚本核心逻辑读清单、按关键词匹配、把匹配到的条目拼成 prompt、调用 TaoToken 返回结构化建议。关键代码片段import json, tomllib from openai import OpenAI with open(settings.toml, rb) as f: cfg tomllib.load(f) client OpenAI( base_urlcfg[taotoken][base_url], api_keycfg[taotoken][api_key], ) with open(cfg[checklist][path], encodingutf-8) as f: checklist json.load(f) def search_bias(keyword): hits [b for b in checklist if keyword in b[name_cn] or keyword in b[name_en] or keyword in b[ux_symptom]] return hits[:cfg[checklist][top_k]] def ask_bias(keyword): hits search_bias(keyword) context \n.join( f{b[id]} {b[name_cn]}: {b[design_check]} for b in hits ) resp client.chat.completions.create( modelcfg[taotoken][model_id], messages[ {role: system, content: 你是UX评审助手基于给定偏差条目回答。}, {role: user, content: f关键词{keyword}\n相关条目\n{context}\n请给出评审建议。}, ], ) return resp.choices[0].message.content print(ask_bias(价格))这段代码里base_url、api_key、model_id三件套齐全路径与 settings.toml 一致。跑之前确认cognitive_bias_checklist.json和脚本在同一目录。如果你用 Cline 或类似工具做 MCP 接入配置里同样要写全三件套。以 Cline 的 MCP 配置为例{ mcpServers: { taotoken-bias: { command: python, args: [bias_server.py], env: { TAOTOKEN_BASE_URL: https://taotoken.net/api, TAOTOKEN_API_KEY: sk-你的Key, TAOTOKEN_MODEL_ID: 你的模型ID } } } }三件套一个都不能少。少 Base URL 会连到默认地址少 Key 会 401少 Model ID 会报模型不存在。下一节验证请求看实际返回。4. 验证请求与成功结果一次批量调用确认清单可消费配置写完后先做单条验证再做批量验证。单条验证确认通道通批量验证确认清单能被程序化消费。单条验证直接跑上一节的ask_bias(价格)。预期返回类似根据 CB-001 锚定效应和 CB-012 损失厌恶价格页评审建议 1. 检查首个展示套餐是否为最高价若是确认是否有意为之 2. 折扣信息是否强调「省了多少」而非「原价多少」 3. 限时优惠是否制造了不必要的时间压力。如果返回这种结构化建议说明通道通了。如果返回报错对照下一节的排查表。批量验证写一个循环把 67 条偏差的review_question逐条发给模型检查每条是否都能返回非空结果import json from openai import OpenAI client OpenAI(base_urlhttps://taotoken.net/api, api_keysk-你的Key) with open(cognitive_bias_checklist.json, encodingutf-8) as f: checklist json.load(f) failed [] for b in checklist: try: resp client.chat.completions.create( model你的模型ID, messages[{role: user, content: b[review_question]}], max_tokens200, ) text resp.choices[0].message.content if not text or len(text) 10: failed.append((b[id], 空返回)) except Exception as e: failed.append((b[id], str(e))) print(f总数 {len(checklist)}失败 {len(failed)}) for fid, reason in failed: print(fid, reason)成功结果应该是总数 67失败 0。如果有失败看下一节。批量验证的意义不只是「确认能调通」而是确认清单的review_question字段质量。如果某条偏差的提问太模糊模型返回也会模糊这种条目在评审会上同样不好用。批量跑一遍等于对清单做了一次质量体检。实测下来67 条里通常有 3 到 5 条需要改写review_question原因是提问里带了「是否」「有没有」这种封闭式问法模型容易只回「是」或「否」。改成开放式比如把「是否有锚点」改成「这个页面第一个出现的数字是什么它如何影响用户对后续价格的判断」返回质量会明显提升。验证通过后清单就可以接入评审流程了。最简单的用法评审前把当前设计稿的关键词比如「价格」「注册」「弹窗」跑一遍检索把命中的偏差条目打印出来会上逐条对照。进阶用法把检索脚本包成内部工具评审时实时查询。下一节处理验证过程中可能遇到的报错。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth验证阶段最常见的四类报错逐个说清楚原因和解法。401 Unauthorized。返回体通常是{error: {message: Invalid API key}}。原因有三个Key 复制时带了空格、Key 已失效、鉴权头格式写错。检查顺序先确认api_key字段没有首尾空格再确认 Key 在控制台里是启用状态最后确认代码里是Authorization: Bearer sk-xxx而不是Authorization: sk-xxx。如果用的是环境变量确认 export 的变量名和代码里读的一致。local proxy failed。这个报错通常出现在本地脚本通过某些工具转发请求时。原因是你本地配置了转发规则但转发目标不可达。解法检查脚本里的base_url是否直接写成https://taotoken.net/api不要经过本地中间层。如果你在用 Cline 或类似工具检查 MCP 配置里的TAOTOKEN_BASE_URL是否被其他环境变量覆盖。最稳妥的做法是在脚本开头打印一次实际使用的 base_url确认它就是你写的那个。reading choices 相关报错。典型信息是AttributeError: NoneType object has no attribute choices或KeyError: choices。这说明响应体里没有choices字段通常是请求根本没成功返回的是错误 JSON。解法在调用后先打印resp原始内容看它到底是成功响应还是错误响应。如果错误信息里有model not found说明 Model ID 写错了去模型对话页面确认正确的 ID。如果错误信息里有max_tokens相关说明参数超限调小即可。OAuth 相关报错。如果你在 Claude Code 或类似工具里配置可能遇到 OAuth 流程报错。这类工具通常要求填 Base URL、Key、Model ID 三件套而不是走 OAuth。检查你的配置里是否误开了 OAuth 模式。以 Claude Code 为例配置应写成{ baseUrl: https://taotoken.net/api, apiKey: sk-你的Key, model: 你的模型ID }三件套齐全不要留空。如果工具提示 OAuth说明它没读到你的 Key 配置检查配置文件路径是否正确。另外两个容易忽略的点一是 JSON 清单文件编码必须用 UTF-8否则中文条目会乱码导致检索失败二是top_k设太大比如设成 10prompt 会很长返回变慢且容易截断建议 3 到 5。排查完这些批量验证应该能跑到失败 0。最后说下清单的日常维护和 CTA 分流。6. 清单维护与调用通道选择把 67 条偏差变成团队资产清单建好后维护比创建更重要。三个实用建议第一给每条偏差加last_reviewed字段记录上次在评审中被引用的日期。半年没被引用的条目要么是分类太偏要么是提问写得不好值得回头改。第二把severity字段和评审流程绑定。高严重度条目在评审时必须逐条确认中低严重度可以抽样。这样清单不只是查询工具而是评审节奏的一部分。第三定期用批量脚本跑一遍全量检查返回质量。模型更新后同样的review_question可能返回不同风格的建议跑一遍能及时发现。调用通道的选择上分三种情况如果只是偶尔查几条偏差用模型对话页面手动查最快入口在 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 如果要把检索脚本接入内部工具用 API Key在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 管理 Key接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 如果要做长期的评审 Agent让它自动跑清单、自动生成评审报告可以了解 Coding Plan入口在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。最后回到清单本身。67 个认知偏差真正高频出现在评审里的可能只有 15 到 20 个。但这不代表其余条目没用——它们的价值在于当评审陷入「我觉得这样不好」的僵局时你能从清单里找到一条命名的偏差把主观感受变成可讨论的客观条目。这才是「可检索决策清单」的真正意义不是替代判断而是给判断提供可追溯的依据。清单文件建议放团队共享仓库脚本和 settings.toml 一起提交Key 用环境变量注入不要提交。这样新人入职拉下来就能跑评审时随时查。从阅读材料到团队资产差的不是工具是字段和通道这两步工程化动作。