前阵子一位做后端的朋友问我AI 都能自己写 CRUD 了我是不是该转行去学点新技能我说你真正该慌的不是技能不够而是判断力不足。最近看到 Notion 产品负责人关于“AI 时代什么更值钱”的分享观点很直接比技能更值钱的是你定义好问题、构建高质量上下文、并最终拍板的能力。这篇文章想把这句听起来像“鸡汤”的话翻译成开发者能落地的能力模型并用一个真实的 Notion API 大模型小项目演示如何把判断力变成可沉淀、可复用的工作流。过去十年技术圈的主流叙事是“学会一门语言、一个框架就能吃十年饭”。但大模型出现后这条曲线的斜率变了代码生成、接口调用、配置排查这些曾经需要长期训练的技能正在被 AI 快速外包。而真正稀缺的变成了“该做什么、不该做什么、做到什么程度”的判断力。读完这篇文章你会理解判断力为什么比技能更值钱也会拿到一套用 Notion 管理决策、用 AI 辅助分析的实操方法可以直接用在自己的项目里。1. 这篇文章真正要解决的问题很多人学了一堆 AI 工具最后产出依然平庸。不是工具不好用而是他们在用“旧技能思维”使用新工具只关心怎么让 AI 写出更长的代码却忽略了 AI 需要什么样的上下文、要产出什么标准的结果、谁来为最终结果负责。Notion 产品负责人那段分享的核心不是在推销 Notion而是在说一个产品逻辑AI 把生产能力变廉价之后人类的价值会向两个方向集中——一是定义问题二是判断结果。写代码、写文案、做表格这些事情AI 都能做但“这个需求值不值得做”“这个方案有没有隐藏风险”“这个输出能不能上线”仍然需要人来回答。这篇文章要解决三个具体问题理解 AI 重塑开发者的能力结构明确“技能贬值”和“判断力升值”背后的技术原因把抽象的判断力拆成可练习的技术动作比如上下文构建、方案对比、风险评审通过一个 Notion API 大模型的项目示例让你亲手跑通“用 AI 辅助判断而不是替代判断”的流程。如果你是正在焦虑被 AI 替代的开发者、需要带团队做 AI 项目的技术负责人或者刚转型 AI 产品经理这篇文章值得看完。2. 核心观点判断力比技能更值钱先说清楚概念。这里的“技能”指那些有明确标准答案的操作能力写一段排序算法、配置一个 Nginx 反向代理、封装一个 REST API。这类技能有两个特点一是可以通过反复练习获得二是结果可以被自动验证。“判断力”则不同。它是在信息不完整、目标不清晰、约束条件互相冲突的情况下做出决策的能力。例如技术方案选型、需求优先级排序、风险边界识别、成本与质量的取舍。这类能力没有标准答案也很难用自动化测试去验证。Notion 产品负责人的观点本质上是在讲一个经济学事实当技能变成可替代品拥有技能的红利就会消失而判断力因为难以复制成为新的稀缺资源。Notion 本身就是这个观点的产品化表达。对比普通笔记软件和 Notion你会发现 Notion 的核心不是帮你记录信息而是帮你组织信息之间的关系、建立知识结构、形成可追溯的决策过程。这种“为判断提供上下文”的能力恰好是 AI 时代最重要的能力。用一句话概括技能解决“怎么实现”判断力解决“做什么、为什么做、做到什么程度”。大模型能帮你把“怎么实现”压缩到几分钟但“做什么”浪费掉的时间才是真正的成本。3. AI 改变的是“技能”的稀缺性不是“判断”的稀缺性3.1 传统开发中的技能阶梯在没有大模型的年代开发者的成长路径通常是先掌握语法再熟悉框架然后理解设计模式最后能做架构决策。在这个阶梯里越往上走的人越稀缺因为架构决策需要多年的项目经验。但 AI 改变的是阶梯下面几层的获取成本。过去写一个复杂查询需要查半天文档现在用自然语言描述就能生成过去排查一个依赖冲突需要反复试错现在把报错粘给 AI 就能拿到方向。这意味着“会写代码”和“能写代码”之间的门槛正在消失。3.2 大模型降低的是执行成本而不是决策成本当一个需求被描述清楚AI 生成代码的速度和完整度已经相当可观。但你仍然要回答这个需求真的成立吗生成出来的代码有没有安全漏洞性能是否满足指标这套方案在未来的可维护性如何这些问题都和“写代码”无关它们属于“判断”。判断的前提是你要对业务、用户、系统约束、成本结构有足够深入的理解。技能可以被模型复制但这种理解很难。3.3 给开发者的启示从“写代码”到“审代码、定方向、做取舍”一个更贴近日常的变化是开发者的日常工作重心正在从“亲手写每一行代码”转向“给 AI 下达高质量指令 严格验收 AI 的输出”。这意味着你需要具备更强的代码审查能力、更清晰的验收标准以及更谨慎的方案边界判断。换句话说AI 把你从“执行层”解放出来让你有机会做“决策层”的事情。但如果你没有决策能力就会变成一个只会转发 Prompt 的人价值反而更低。4. 技术视角判断力在 AI 工程中的四个落点把“判断力”放到技术工程里它具体体现在四个地方。4.1 问题定义把模糊需求变成可执行任务很多 AI 项目失败不是因为模型不够强而是因为问题没有定义清楚。比如“做一个智能客服”就是一个模糊问题而“当用户询问订单状态时先调用订单查询接口再把结果用 100 字以内回复”才是可执行任务。判断力在这里体现为你能把业务目标拆成 AI 可以理解的任务边界、输入输出格式和异常处理规则。拆得越清楚AI 的产出越可控。4.2 上下文工程决定 AI 输出质量的关键同一道题有人让 AI 回答得很好有人得到的却是泛泛而谈。差异往往在 Prompt 和上下文。给 AI 提供足够的背景信息、明确的约束条件、示例输出、评价标准才能得到稳定且专业的结果。你可以把 Prompt 看作“给 AI 铺一条水渠”水渠修到哪里水流就到哪里。判断力就是修水渠的能力。4.3 验证体系判断 AI 输出能否上线验证是 AI 应用中最容易被忽视的环节。你要设计一套评估标准准确率、覆盖率、用户反馈、fallback 策略。哪些情况可以直接用 AI 结果哪些必须人工复核哪些需要降级到规则引擎这已经不是 Prompt 层面的技术而是产品层面的判断。能设计出合理验证体系的人在团队里很难被替代。4.4 决策记录让判断可追溯、可复用判断力不是天生的可以在实践中训练。但很多人的问题是判断过程不透明当时为什么选这个方案有没有考虑过替代方案事后复盘时完全没有记录。记录决策日志是最简单也最有效的训练方式。常见做法是需求背景、目标、方案对比、选择理由、风险、复盘结果。这个流程完全可以和 Notion 结合由 AI 辅助整理人类负责拍板。5. 实战用 Notion API 搭建 AI 决策辅助系统下面进入可操作的部分。我们要做一个小系统把团队的技术决策记录在 Notion 数据库里用 Python 脚本读取未完成的决策项调用大模型生成方案建议和风险提示再把结果写回 Notion最后由人类确认和修改。这套流程解决的核心问题是AI 不是直接替你做决定而是辅助你快速生成候选方案和风险清单人来负责最终判断。整个过程可沉淀、可追溯、可复盘。5.1 环境准备与前置条件需要准备的环境如下Python 3.9 及以上推荐 3.10一个 Notion 账号以及一个用于 API 访问的 Integration一个可以调用的大模型 API支持 OpenAI 兼容接口即可安装requests和python-dotenv用于请求和配置读取。安装依赖pip install requests python-dotenv5.2 创建 Notion 集成与数据库登录 Notion 后进入 Settings → Integrations → Develop or manage integrations创建一个内部集成记录 Token。然后在需要使用的页面中点击菜单连接把刚才创建的 Integration 添加为页面成员。创建数据库时推荐添加以下字段字段类型说明标题Title决策项标题需求背景Rich text背景信息、约束条件备选方案Rich textAI 读取后可以参考的方案AI 输出Rich textAI 生成的建议和风险状态Select待处理、已完成数据库创建完成后从浏览器地址栏可以拿到数据库 ID。数据库 URL 的格式通常是https://www.notion.so/xxx/数据库ID?v...其中数据库ID是 32 位十六进制字符串。后续会用到。为了安全把配置写入.env文件并在.gitignore中忽略它NOTION_TOKENsecret_xxx NOTION_DATABASE_IDyour_database_id LLM_API_KEYyour_llm_api_key LLM_BASE_URLhttps://api.openai.com/v1 LLM_MODELyour-model-name注意LLM_MODEL请替换为你实际可用的模型名称各地模型服务的接口路径不完全一致以官方文档为准。5.3 Python 读取 Notion 数据库先写一个读取数据库的工具函数。Notion API 的认证方式是 Bearer Token同时需要指定 Notion API 版本。# decision_assistant.py import os import requests from dotenv import load_dotenv load_dotenv() NOTION_TOKEN os.getenv(NOTION_TOKEN) DATABASE_ID os.getenv(NOTION_DATABASE_ID) LLM_API_KEY os.getenv(LLM_API_KEY) LLM_BASE_URL os.getenv(LLM_BASE_URL, https://api.openai.com/v1) LLM_MODEL os.getenv(LLM_MODEL, your-model-name) NOTION_VERSION 2022-06-28 def query_notion_database(): url fhttps://api.notion.com/v1/databases/{DATABASE_ID}/query headers { Authorization: fBearer {NOTION_TOKEN}, Notion-Version: NOTION_VERSION, Content-Type: application/json, } resp requests.post(url, headersheaders, json{page_size: 10}) resp.raise_for_status() return resp.json().get(results, [])函数通过 POST 方式请求 Notion 的查询接口常见问题是权限不足。如果返回 401说明 Token 无效返回 404说明数据库 ID 有误或者集成没有连接到该页面。5.4 提取待处理决策项数据库中的每一行是一个页面对象字段都放在properties中。我们需要筛选出状态不是“已完成”的行。def extract_decision_rows(rows): items [] for row in rows: props row.get(properties, {}) title_prop props.get(标题, {}).get(title, []) title title_prop[0][plain_text] if title_prop else 无标题 status_prop props.get(状态, {}).get(select) status_name status_prop.get(name, ) if status_prop else if status_name 已完成: continue background_prop props.get(需求背景, {}).get(rich_text, []) background .join([t.get(plain_text, ) for t in background_prop]) items.append({ page_id: row[id], title: title, background: background, status: status_name, }) return items这里使用了中文属性名作为 JSON key如果你在 Notion 中使用了不同字段名需要同步修改。5.5 调用大模型生成建议并写回 Notion接下来定义两个关键函数调用大模型接口生成建议以及将结果更新回 Notion 页面。def call_llm(prompt: str) - str: url f{LLM_BASE_URL}/chat/completions headers { Authorization: fBearer {LLM_API_KEY}, Content-Type: application/json, } payload { model: LLM_MODEL, messages: [ {role: system, content: 你是技术决策助手帮助开发者整理方案与风险。}, {role: user, content: prompt}, ], temperature: 0.2, } resp requests.post(url, headersheaders, jsonpayload, timeout60) resp.raise_for_status() return resp.json()[choices][0][message][content] def update_notion_property(page_id: str, property_name: str, content: str): url fhttps://api.notion.com/v1/pages/{page_id} headers { Authorization: fBearer {NOTION_TOKEN}, Notion-Version: NOTION_VERSION, Content-Type: application/json, } data { properties: { property_name: { rich_text: [{type: text, text: {content: content}}] } } } resp requests.patch(url, headersheaders, jsondata) resp.raise_for_status() def main(): rows query_notion_database() decisions extract_decision_rows(rows) for item in decisions: prompt f 请基于以下需求背景给出一个开发方案建议和 3 个关键风险点。 需求标题{item[title]} 需求背景{item[background]} 输出格式 方案建议 风险点 1. 2. 3. try: suggestion call_llm(prompt) except Exception as e: suggestion f生成失败{e} update_notion_property(item[page_id], AI 输出, suggestion) print(f已处理{item[title]}) if __name__ __main__: main()这段脚本的核心逻辑是读取未完成决策 → 构造 Prompt → 调用大模型 → 写回 Notion。注意大模型输出必须经过人工确认不要直接当成最终结果。脚本里的temperature设置为 0.2是为了让输出更稳定减少发散。6. 运行结果与效果验证在本目录下执行python decision_assistant.py如果一切正常控制台会输出已处理订单模块技术方案 已处理缓存迁移方案同时打开 Notion 数据库你会看到对应行的“AI 输出”字段被自动填充。如何判断是否成功AI 输出字段出现了结构化文本说明 API 调用链路正常如果只有部分行被处理说明某些行缺少需求背景字段被提取为空字符串但脚本仍会执行如果脚本直接报错优先检查.env中的NOTION_TOKEN和DATABASE_ID。一个常见的验证技巧是先在 Notion 里手动建一条测试数据把背景写清楚再运行脚本。这样可以确认配置没有问题再录入更多数据。7. 常见问题与排查方法问题现象可能原因排查方式解决方案调用 Notion API 返回 401Token 错误或权限范围不足查看 Notion Integration 的 Token 是否被复制完整重新生成 Token确认在 Notion 页面已添加该集成返回 404数据库 ID 错误或没有读取权限检查 URL 中数据库 ID 是否正确复制正确的数据库 ID确认集成已连接到该页面无法识别数据库字段属性名不匹配打印props信息将 Python 中的中文字段名改为数据库实际字段名大模型接口超时网络问题或模型响应时间过长查看requests.exceptions.Timeout信息增大timeout参数或替换为延迟更低的模型服务写回 Notion 失败属性类型不是 rich_text检查字段类型将“AI 输出”字段配置为 Rich text 类型Prompt 输出不稳定模型参数设置过于发散降低temperature建议设为 0.1 到 0.3 之间8. 最佳实践与工程建议这套示例可以作为起点但真正在生产中使用还需要注意几个问题。8.1 决策记录模板化不要随意在 Notion 里写决策。建议固定为背景、目标、约束、方案对比、选择理由、风险、负责人、复盘结论。字段化之后AI 才能稳定读取也才能在未来形成可检索的团队知识库。8.2 权限最小化Notion Integration 的权限要遵循最小化原则只给需要的页面和数据库授权不要给整个 Workspace 全量权限。如果脚本被误用最大限度控制影响范围。8.3 大模型输出要有人工验收环节示例脚本直接把输出写回 Notion但不代表这就是最终结果。更稳妥的流程是AI 输出 → 人工评审 → 修改状态为“已完成”。你可以在脚本里多写一个“评审意见”字段由人来填写。8.4 不要把 Prompt 写成一次性代码Prompt 建议抽成模板放在单独的文件中方便版本管理。例如prompts/decision_prompt.txt脚本读取模板再填入数据。这样团队可以像维护代码一样维护 Prompt。8.5 用上下文构建提升输出质量当前示例只传入了需求背景。实际使用中你还可以把相关文档、历史决策、团队标准一并拼进 Prompt。这就是上下文工程的作用。上下文越完整AI 输出越接近团队的真实语境。8.6 从“辅助判断”升级到“自动化工作流”当流程跑通后你可以继续扩展状态变更时自动通知相关人完成后自动把决策发送到周报数据库或者定期把历史决策交给 AI 做复盘分析。这里的核心仍然是AI 能够加速过程但最终判断必须有人参与。9. 总结与后续学习方向回到开头的问题AI 时代比技能更值钱的是什么是定义问题的能力、构建上下文的能力、评估风险与取舍的能力也就是判断力。技能仍然重要因为它是判断力的基础但技能不再稀缺稀缺的是把技能放在正确位置的能力。你不需要成为 Prompt 大师也不需要背下所有 API但你需要建立一套自己的“判断工作流”把需求写清楚、把方案结构化、把风险显性化、把决策沉淀下来。Notion 可以帮你管住信息本文的 Python 示例可以帮你快速生成候选方案但最终拍板的人依然是你。下一步可以继续研究三个方向一是把 Notion 数据库作为 AI Agent 的记忆层让 Agent 在需要时自动检索相关决策二是用 RAG 方式把团队知识库作为上下文让 AI 更懂项目历史三是搭建更完整的验证机制为每个 AI 输出设计 check list 和回滚方案。判断力的训练没有终点但每一份记录、每一次复盘都会让你在下一次面对模糊问题时更确定一点。