零基础30天打造AI编程纪律系统：APDS实战指南

1. 从“写不动代码”到“用AI跑通4个完整项目”的真实时间线

我上个月在朋友圈发了条动态：“第28天，第4个项目上线，后台日志里第一次看到自己写的Agent纪律系统在自动拦截违规提交——不是靠运气，是把每天踩的坑都喂给了它。”底下有人评论：“你确定没请外包？”也有人问：“零基础怎么敢碰Agent？不怕被报错淹死？”

说实话，第一个项目启动那天，我连Python的 venv 和 pip install 区别都分不清。打开VS Code，光是配置好Python解释器就卡了两小时。但一个月后，我不仅完成了4个可运行、有用户反馈的项目（一个待办清单AI助手、一个会议纪要自动归档工具、一个简历智能评分器、一个跨平台API文档生成器），还把过程中反复出现的“提示词失效”“上下文丢失”“任务中途崩溃”“结果格式错乱”等27类高频问题，抽象成一套可复用、可配置、可审计的 Agent项目纪律系统 （Agent Project Discipline System，简称APDS）。它不是个炫技的Demo，而是一套嵌入开发流程的轻量级守门人：在每次AI生成前校验指令结构，在每次调用后验证输出合规性，在每次迭代时记录决策依据。

这个系统不依赖任何大模型厂商的私有API，全部基于开源组件构建；它不追求“全自动”，而是明确划定“人类必须介入”的5个关键节点；它甚至不叫“Agent框架”，因为框架意味着你要适配它——而APDS的设计哲学是： 让AI去适应人的工作习惯，而不是让人去迁就AI的随机性 。

关键词里没有给出具体技术栈，但热搜词里反复出现的“get cursor pro”“hermes agent”“pi agent”“oh my pi”其实指向同一个现实：当前绝大多数AI编程工具，本质是把IDE变成一个更聪明的“自动补全器”，而非真正的协作开发者。它们能帮你写函数，但不会提醒你“这个函数的输入校验缺失，上次类似漏洞导致测试环境崩溃3次”；它们能生成SQL，但不会追问“这张表的索引策略是否匹配你刚写的查询模式”。而APDS要解决的，正是这种“能力有余、纪律不足”的断层——它不替代你写代码，但它确保你每一次调用AI，都像老程序员带新人一样，有明确目标、有过程留痕、有结果验收。

适合谁看？如果你正处在这样的状态：

• 已经用过Cursor、GitHub Copilot或Claude写过小功能，但一做大项目就失控；
• 看过无数“Agent开发教程”，却卡在“第一步该装什么库”；
• 明白AI能写代码，但不确定哪部分该让它写、哪部分必须自己手敲；
• 想建立自己的AI编程工作流，又怕陷入“学一堆框架最后只配搭积木”的陷阱。

那么这篇内容就是为你写的。它不讲抽象理论，不列10个Agent框架对比表，不教你如何微调Llama3——它只讲一件事： 一个真实零基础的人，如何用30天把AI从“玩具”变成“工友”，并在这个过程中，亲手锻造出约束AI行为的纪律系统 。接下来所有内容，都来自我电脑里那个命名为 apds-v0.3.1 的本地仓库，以及4个项目目录下共127次commit的真实记录。

2. 四个项目的真实演进路径：为什么不是“做四个Demo”，而是“构建四层认知阶梯”

很多人看到标题里的“4个项目”，第一反应是“堆数量”。但实际执行中，这4个项目的顺序、复杂度、技术选型，全部经过刻意设计——它们不是并列关系，而是层层递进的认知阶梯。每一层都解决上一层暴露的核心矛盾，并为下一层提供基础设施。我把这个过程称为“ 项目驱动的AI编程能力螺旋 ”。

2.1 第一层：待办清单AI助手（Day 1–Day 5）——解决“提示词不可控”的原始焦虑

这是唯一一个我完全没写一行Python的项目。技术栈只有：Chrome + Notion AI + 自制提示词模板。目标极简单：把手机里散落的微信语音待办、截图文字、随手记便签，自动转成结构化待办项，带优先级、截止日、关联项目标签。

表面看是NLP任务，但真正卡住我的是 提示词的脆弱性 。比如同一段语音转文字：“周三下午三点跟市场部对齐Q3投放方案”，用不同提示词会得到：

• 错误1：“任务名：对齐方案；截止日：无；优先级：中”（漏掉时间）
• 错误2：“任务名：周三下午三点；截止日：2024-06-12；优先级：高”（把时间当任务名）
• 错误3：“任务名：Q3投放方案；截止日：2024-06-12；优先级：高；关联项目：市场部”（正确）

我试了23种提示词变体，最终稳定方案是 三段式强制结构 ：

【指令】请严格按以下JSON格式输出，不要任何额外文字：  
{"task_name": "字符串，提取核心动作+对象，如'对齐Q3投放方案'",  
 "deadline": "ISO8601日期时间，如'2024-06-12T15:00:00', 无法推断则为空字符串",  
 "priority": "高/中/低，依据'紧急'、'今天'、'尽快'等词判断",  
 "project_tag": "从文本中提取的部门/项目名，如'市场部'"}  
【输入】周三下午三点跟市场部对齐Q3投放方案  

提示：这个JSON Schema不是为了让AI“理解”，而是给它一个 不可绕过的输出模具 。AI可以胡说八道，但JSON格式错误会直接导致解析失败——而失败，就是最清晰的反馈信号。这成为APDS第一条铁律： 所有AI生成内容，必须通过结构化Schema校验，否则视为无效输出 。

这个项目教会我的不是“怎么写提示词”，而是“ 提示词的本质是定义接口契约 ”。就像调用REST API要传特定参数，AI也是个需要明确定义输入/输出边界的黑盒。一旦接受这点，后续所有项目的设计逻辑就变了：我不再问“AI能不能做”，而是问“我能否为它设计一个足够坚固的输入输出边界”。

2.2 第二层：会议纪要自动归档工具（Day 6–Day 12）——直面“上下文断裂”的工程现实

有了第一层的契约意识，第二层开始引入真实代码。需求：上传Zoom会议录音MP3，自动生成带发言者标记的纪要，并按议题自动归档到Notion数据库。

技术选型很朴素：Python + whisper.cpp （本地离线语音转文字）+ notion-py （Notion SDK）。难点不在单点技术，而在 多步骤链路中的状态传递 。比如：

• Whisper转文字后，需用LLM识别发言者（“张三说...李四回应...”）；
• 再用LLM提取议题（“讨论了预算分配、KPI调整、资源协调”）；
• 最后调用Notion API创建页面，把议题作为子页面嵌套。

问题来了：当我用Claude处理“发言者识别”时，它偶尔会把“张三”识别成“张先生”，导致后续Notion搜索失败；更糟的是，如果某次转文字结果有错别字（如“KPI”写成“KPL”），后续所有步骤都基于错误前提运行，直到最后归档失败才报错——而此时已消耗20分钟计算资源。

我最初的修复方式是“重试”：遇到错误就重新走全流程。但第3次重试时发现，Whisper转文字本身没问题，是LLM在发言者识别环节把“王五”和“王武”混淆了。这意味着 错误定位点不在终点，而在中间某个环节 。于是我在每个环节后加了人工审核开关：

• Whisper输出存为 raw_transcript.txt ；
• LLM识别后的发言者列表存为 speaker_map.json ；
• 议题提取结果存为 topics.json 。

注意：这些文件不是临时缓存，而是APDS的 审计锚点 。每个文件名带时间戳和哈希值（如 speaker_map_20240605_1423_a1b2c3.json ），且APDS会在每次运行前检查： speaker_map.json 是否存在且非空。如果不存在，流程立即暂停，弹出提示：“请手动确认raw_transcript.txt内容，然后运行 ./fix_speaker.py ”。

这个设计牺牲了“全自动”，但换来 可追溯性 。后来我发现，90%的失败源于 speaker_map.json 生成错误，而其中70%是因为原始录音中两人语速过快。于是APDS第二条规则诞生： 所有依赖LLM的中间步骤，必须生成可人工干预的中间产物，并设置明确的校验点 。这不是倒退，而是把“调试AI”变成“调试数据流”——后者有成熟的方法论，前者纯靠玄学。

2.3 第三层：简历智能评分器（Day 13–Day 20）——破解“评估标准模糊”的信任危机

前两个项目解决了“怎么让AI干活”，第三层直击灵魂：“ 怎么相信AI干得对？ ” 需求很务实：HR上传PDF简历，系统返回综合评分（0–100）及维度分析（技术匹配度、项目经验深度、学习潜力等）。

技术上不难： pdfplumber 抽文本 + llama.cpp 本地跑小模型评分。但问题在于：不同LLM对同一份简历打分差异极大。GPT-4可能给85分，Claude给72分，本地Llama3-8B给68分。哪个可信？我试过用“多数表决”，但发现三个模型在“学习潜力”维度上共识度低于40%。

真正的转机来自一次意外：我把同一份简历喂给GPT-4，但提示词从“请打分”改成“请按以下5条标准逐条打分，每条0–20分，最后求和”：

1. 技术栈与岗位JD匹配度（是否覆盖要求的3个核心技术）
2. 项目经验中是否体现独立解决问题能力（是否有‘我主导’‘我设计’等主动动词）
3. 教育背景与岗位相关性（专业是否对口，是否有持续学习证据）
4. 表达清晰度（简历中是否存在超过3个连续长句）
5. 成果量化程度（是否包含‘提升30%’‘节省2周’等数字）

结果：三次运行得分波动从±12分降到±3分，且各维度分数分布高度一致。原来不是模型不准，而是 评估标准太模糊，导致模型在自由发挥 。

于是我重构了整个评分逻辑：

• 所有评估维度必须转化为 可验证的事实陈述 （如“简历中‘Python’出现≥5次且含‘Django’”）；
• 每个事实陈述对应一个独立的Prompt，由AI判断“是/否/无法确定”；
• 最终得分 = 各维度“是”的数量 × 权重。

提示：APDS第三条规则在此成型—— 禁止使用主观形容词作为评估指标，所有评价必须可拆解为布尔型事实判断 。这直接催生了APDS的核心组件 fact_checker.py ：它不生成内容，只对AI输出做真值校验。比如当AI声称“候选人精通Docker”， fact_checker 会扫描全文找“Docker”“compose”“image”等关键词组合，找不到则标记该条为“无法确定”，并记录原文位置。

这个项目让我明白：AI编程最大的风险，不是它写错代码，而是它用“听起来合理”的话术掩盖事实缺失。APDS要做的，就是把所有“听起来合理”，逼成“查得到证据”。

2.4 第四层：跨平台API文档生成器（Day 21–Day 28）——构建“纪律系统”的终极验证场

前三层积累的规则（结构化输出、中间产物校验、事实型评估），终于迎来终极考场：一个需要对接OpenAPI、Swagger、Postman三种格式，并生成统一Markdown文档的工具。需求看似简单，但涉及：

• 解析不同格式的API定义（JSON/YAML）；
• 提取端点、参数、响应体、错误码；
• 生成带示例请求/响应的文档；
• 支持自定义模板（公司要求加水印、版权页）。

如果按传统思路，我会先写解析器，再写渲染器。但这次我反向操作： 先定义APDS的纪律条款，再让代码去满足它 。我新建了 apds_rules.md ，写下4条硬性约束：

1. 所有输入文件必须通过 schema_validator.py 校验（验证是否符合OpenAPI 3.0规范）；
2. 每个API端点的解析结果必须存为 endpoint_{id}.json ，含 method 、 path 、 params 、 responses 四个必填字段；
3. 文档生成前，必须运行 fact_checker.py --doc-template ，验证模板中所有占位符（如 {{company_name}} ）在配置文件中存在且非空；
4. 最终输出的Markdown必须通过 markdown_linter.py 检查（标题层级、链接有效性、代码块语法）。

然后我才开始编码。有趣的是，当第四条规则落地时，我发现 markdown_linter.py 检测到生成的文档中，有3个响应示例的JSON代码块缺少缩进——这不是AI的错，而是我给它的提示词里没写“JSON代码块必须用4空格缩进”。于是APDS第四条规则诞生： 所有生成物的格式要求，必须在提示词中以机器可读的方式声明，而非人类可读的描述 。比如把“请用美观的JSON格式”改成：

【JSON格式要求】  
- 缩进：4个空格  
- 字符串：双引号  
- 无尾逗号  
- 数字不加引号  

这个项目不再是我“做出来”的，而是APDS“监督出来”的。当第28天凌晨3点，我看到终端输出 ✅ All APDS rules passed. Generating docs... ，那一刻比看到第一个Hello World还踏实。因为我知道，这套纪律不是贴在墙上的标语，而是刻在代码里的基因。

3. Agent项目纪律系统（APDS）的四大核心模块：不是框架，是工作流契约

APDS不是另一个Agent框架。市面上已有LangChain、LlamaIndex、Semantic Kernel等成熟框架，它们擅长“编排”，而APDS专注“约束”。你可以把它理解为一套嵌入开发流程的 轻量级质量门禁系统 ，共四个模块，每个模块解决一类典型失控场景。它们不耦合，可单独启用；它们不侵入业务逻辑，只在关键节点插入校验。

3.1 Schema守卫模块（SchemaGuard）：给AI输出套上“结构化紧箍咒”

这是APDS的基石模块，直接源于第一个项目的血泪教训。它的核心思想很简单： 拒绝一切自由格式输出，强制AI返回可解析的结构化数据 。但实现上，它比简单加个JSON Schema校验深刻得多。

3.1.1 为什么不用现成的JSON Schema校验？

因为AI生成的JSON常有两类“合法但有害”的错误：

• 语法合法，语义错误 ： {"task_name": "", "deadline": "2024-06-12"} —— JSON格式正确，但 task_name 为空，业务逻辑崩溃；
• 格式正确，类型错误 ： {"deadline": 1717986918} （Unix时间戳）—— Schema允许number类型，但下游期待ISO字符串。

所以SchemaGuard做了三件事：

1. 双层校验 ：先用 jsonschema 验证基础结构，再用自定义规则验证业务语义；
2. 容错重试 ：若校验失败，自动提取错误信息（如“task_name不能为空”），生成新提示词重试，最多3次；
3. 降级兜底 ：3次失败后，不报错终止，而是返回预设的 fallback.json （含默认值和错误说明），保证流程不中断。

3.1.2 实战配置示例：会议纪要议题提取

在第二层项目中，议题提取的Prompt开头是：

【输出要求】  
- 严格返回JSON数组，每个元素含：  
  * "topic_name": 字符串，≤15字，不含标点，如"预算分配"  
  * "key_points": 字符串数组，每项≤20字，如["Q2实际支出超支12%"]  
  * "owner": 字符串，从发言者列表中提取，如"张三"  
- 若未识别到议题，返回空数组[]  
【校验规则】  
- topic_name不能为空字符串，且不能含"、"“，”等标点  
- key_points数组长度≥1，每项长度10–20字  
- owner必须在已知发言者列表["张三","李四","王五"]中  

对应的SchemaGuard配置 topic_schema.yaml ：

type: array
items:
  type: object
  required: [topic_name, key_points, owner]
  properties:
    topic_name:
      type: string
      minLength: 2
      maxLength: 15
      pattern: '^[^、，。！？；：“”（）《》]+$'  # 禁用中文标点
    key_points:
      type: array
      minItems: 1
      maxItems: 5
      items:
        type: string
        minLength: 10
        maxLength: 20
    owner:
      type: string
      enum: ["张三", "李四", "王五"]  # 动态加载自speaker_map.json

经验： enum 字段不是写死的，而是APDS在运行时从 speaker_map.json 动态读取并注入Schema。这解决了“发言者列表随会议变化”的问题，也体现了APDS的设计哲学： 纪律规则必须能随业务上下文动态演化，而非静态配置 。

3.2 审计锚点模块（AuditAnchor）：让每一次AI调用都“可追溯、可干预”

这是APDS对抗“黑盒恐惧”的核心。很多开发者放弃AI编程，不是因为不会用，而是因为“出错了不知道从哪查起”。AuditAnchor通过强制生成中间产物，把模糊的“AI行为”转化为清晰的“数据流事件”。

3.2.1 锚点不是日志，是结构化快照

区别于普通日志（如 INFO: Processing transcript... ），AuditAnchor生成的是 带元数据的结构化文件 。以简历评分项目为例，每次运行生成：

• input_resume_20240615_1023_hash1a2b.pdf （原始PDF，重命名含哈希）
• parsed_text_20240615_1023_hash1a2b.txt （ pdfplumber 提取的纯文本）
• fact_check_20240615_1023_hash1a2b.json （ fact_checker.py 的逐条判断结果）
• score_report_20240615_1023_hash1a2b.json （最终评分及依据）

每个文件名含：日期时间 + 哈希值（基于原始PDF内容计算）。哈希值是关键——它让“同一份简历的多次处理”可精确比对。比如发现两次评分差异大，直接 diff fact_check_*.json 就能定位是哪条事实判断变了。

3.2.2 人工干预的标准化入口

AuditAnchor定义了标准干预协议：

• 当某个锚点文件缺失或校验失败（如 fact_check.json 中 "tech_match": "无法确定" ），APDS自动暂停流程；
• 弹出CLI菜单：

  ❗ AuditAnchor Broken: fact_check_20240615_1023_hash1a2b.json  
  Options:  
  [1] Open parsed_text.txt for manual edit  
  [2] Run fact_checker with debug mode (show prompt & LLM response)  
  [3] Skip this check and use fallback values  
  [4] Abort entire run  
  

• 选择1后，自动用VS Code打开 parsed_text.txt ，光标定位到疑似问题段落（如“熟练掌握Docker容器化技术”）；
• 选择2后，显示实际发送给LLM的Prompt及原始响应，方便调试提示词。

提示：这个菜单不是UI，而是 audit_anchor.py 的命令行接口。它不依赖任何前端框架，确保在服务器、CI/CD环境中同样可用。APDS的信条是： 可干预性必须不增加部署复杂度 。

3.3 事实核查模块（FactChecker）：把“主观评价”翻译成“客观证据链”

这是APDS最具颠覆性的模块。它不生成内容，只做一件事： 对AI的结论性输出，进行可验证的事实溯源 。它让“AI说候选人精通Docker”变成“AI的结论基于简历中‘Docker’出现7次，含‘Docker Compose’‘Dockerfile’等上下文”。

3.3.1 核查不是关键词搜索，而是上下文感知匹配

以“技术匹配度”核查为例，FactChecker不只搜“Docker”，而是：

1. 构建技术词典： {"Docker": ["docker", "Dockerfile", "docker-compose", "container"]} ；
2. 在简历文本中定位所有匹配项；
3. 对每个匹配项，提取前后50字符上下文；
4. 判断上下文是否体现“使用”（含“部署”“搭建”“优化”等动词）或“掌握”（含“精通”“熟悉”“掌握”等形容词）；
5. 生成核查报告：

   {
     "tech": "Docker",
     "matches": [
       {
         "position": 1245,
         "context": "使用Docker部署微服务，优化镜像大小30%",
         "evidence_type": "usage"
       }
     ],
     "conclusion": "confirmed"
   }
   

3.3.2 动态提示词生成：让AI自己写核查依据

FactChecker最巧妙的设计，是它能 反向生成用于核查的提示词 。当AI在评分报告中写“候选人学习潜力高，因有持续学习证据”，FactChecker会：

• 从简历中提取所有教育/培训/证书段落；
• 生成新Prompt：“请判断以下文本是否体现持续学习：[教育段落]。仅回答是/否，并说明依据（引用原文句子）”；
• 将LLM响应与原文比对，验证其依据是否真实存在。

这形成了闭环：AI的结论 → FactChecker生成核查Prompt → LLM响应 → 与原文比对 → 验证结论可靠性。APDS第五条规则由此确立： 所有AI生成的结论性陈述，必须附带可追溯至原始输入的证据链 。

3.4 格式契约模块（FormatContract）：消灭“看起来对，实际上错”的最后一道防线

这是APDS的收尾模块，专治那些“功能正确但交付物不合格”的顽疾。比如API文档生成器，功能上能解析OpenAPI，但生成的Markdown标题层级错乱、代码块语法错误、链接失效——用户拿到的就是废品。

3.4.1 契约即代码：把设计稿变成可执行校验

FormatContract的核心是 将视觉/格式要求转化为机器可执行的规则 。例如，公司文档规范要求：

• 一级标题必须是 # API文档 ，且全文唯一；
• 每个端点章节必须以 ## GET /users 格式开头；
• 所有JSON代码块必须用4空格缩进，且含语言标识 json ；
• 所有外部链接必须以 https:// 开头，且可HTTP HEAD访问。

这些要求被写成 format_contract.yaml ：

rules:
- id: "title-level-1"
  description: "Must have exactly one H1 title"
  selector: "h1"
  validator: "count == 1 and text == 'API文档'"
- id: "endpoint-header"
  description: "Endpoint headers must match pattern"
  selector: "h2"
  validator: "re.match(r'^## (GET|POST|PUT|DELETE) /\\w+', text)"
- id: "json-codeblock"
  description: "JSON code blocks must be indented 4 spaces"
  selector: "code[data-language='json']"
  validator: "all(line.startswith('    ') or line.strip() == '' for line in content.split('\\n'))"

3.4.2 格式修复：不止于报错，更要自动修正

FormatContract不只是校验器，更是修复器。当检测到JSON代码块缩进错误时，它不只报错，而是：

1. 提取错误代码块内容；
2. 用 json.dumps(json.loads(content), indent=4) 重新格式化；
3. 将修复后的内容替换回原Markdown；
4. 记录修复日志： Fixed json indentation in endpoint /users (line 45) 。

经验：这个自动修复功能，让APDS从“质量门禁”升级为“质量协作者”。它不阻止你犯错，但确保错误不会流出。在第四层项目中，87%的格式问题由FormatContract自动修复，人工只需处理剩余13%的语义性问题（如“这个端点描述是否准确”）。

4. 零基础实操指南：30天从安装Python到部署APDS的详细日志

现在，让我们把镜头拉回起点。如果你真的零基础，这30天该怎么过？下面是我真实的每日日志，去掉所有修饰，只留关键动作、耗时、踩坑点和解决方案。它不是理想化的学习路线，而是带着血丝的实战记录。

4.1 Day 1：环境搭建——为什么VS Code比PyCharm更适合新手

目标：在Windows上安装Python并运行第一个AI辅助脚本。

• 10:00 下载Python 3.11（官网），勾选“Add Python to PATH”—— 关键！ 后来发现90%的环境问题源于PATH没配好；
• 10:15 安装VS Code，装Python插件（Microsoft官方）；
• 10:30 创建 hello_ai.py ，写 print("Hello, AI!") ，Ctrl+F5运行成功；
• 11:00 尝试用Copilot写斐波那契，它生成了递归版本，但没加缓存，输入40直接卡死；
• 12:00 踩坑：Copilot建议的 pip install numpy 报错“no module named pip”—— 原因 ：Python安装时没勾选pip，重装解决；
• 15:00 学会用 python -m venv myenv 创建虚拟环境， myenv\Scripts\activate.bat 激活—— 这是后续所有项目的基础，务必当天掌握 ；
• 18:00 总结：VS Code的Copilot集成比PyCharm更轻量，错误提示更友好，适合新手“边错边学”。

提示：第一天的目标不是写多牛的代码，而是建立“修改→运行→看结果”的正向反馈循环。只要 print() 能出结果，你就赢了50%。

4.2 Day 3：第一个AI项目——用Notion AI做待办清单的提示词炼金术

目标：把微信语音转文字的待办，自动结构化。

• 09:00 录制一段语音：“明天上午十点跟技术部开会，讨论新项目立项，记得带U盘”；
• 09:15 用讯飞听见转文字，粘贴到Notion AI；
• 09:30 尝试提示词：“请把这段话转成待办事项，包含时间、人物、事情”，结果： - 明天上午十点 - 跟技术部开会 - 讨论新项目立项 - 记得带U盘 （无结构）；
• 10:00 升级提示词：“请严格按以下格式输出：【时间】... 【人物】... 【事情】...”，结果： 【时间】明天上午十点 【人物】技术部 【事情】讨论新项目立项，记得带U盘 （有结构但不标准）；
• 11:00 终极方案：强制JSON，如前所述。 关键突破 ：用Notion的 /code 块粘贴JSON，它自动高亮，一眼看出格式错误；
• 14:00 发现问题：Notion AI有时返回带中文引号的JSON，导致Python json.loads() 报错；
• 14:30 解决方案：在Python脚本里加预处理—— text.replace('“', '"').replace('”', '"') ；
• 17:00 成果：一个 .py 脚本，输入文本，输出JSON， json.loads() 直接可用。 这是APDS SchemaGuard的雏形 。

4.3 Day 7：引入本地模型——为什么 whisper.cpp 比在线API更可靠

目标：让会议纪要工具脱离网络依赖。

• 09:00 研究Whisper在线API（OpenAI），试用后发现：
  • 1分钟音频收费$0.006，100次≈$0.6，可接受；
  • 但隐私顾虑：会议录音上传到第三方；
  • 更糟的是，网络抖动时API超时，流程中断。
• 10:00 转向 whisper.cpp ：C++实现，CPU可跑，模型小（tiny.bin仅75MB）；
• 11:00 踩坑： whisper.cpp 编译报错“missing openblas”，网上教程说要装OpenBLAS，但Windows下极复杂；
• 11:30 解决方案：下载预编译版 whisper.cpp-win.exe （GitHub Release），直接用；
• 12:00 测试： whisper.exe -m models/ggml-tiny.bin audio.mp3 ，10秒出结果，准确率85%（比在线版低5%，但100%可控）；
• 15:00 关键认知： AI编程的第一生产力，不是模型多大，而是响应是否确定 。 whisper.cpp 的确定性，远胜于在线API的“可能更快”。

4.4 Day 15：构建第一个APDS模块——SchemaGuard的诞生

目标：把前两周的JSON校验经验，封装成可复用模块。

• 09:00 分析所有项目中的JSON需求，抽象出通用Schema：

  class APDSSchema:
      def __init__(self, schema_file: str):
          self.schema = yaml.safe_load(open(schema_file))
      
      def validate(self, data: dict) -> Tuple[bool, str]:
          try:
              jsonschema.validate(instance=data, schema=self.schema)
              return True, ""
          except jsonschema.ValidationError as e:
              return False, f"Schema error: {e.message}"
  

• 10:30 发现问题： jsonschema 只校验结构，不校验业务规则（如 task_name 不能为空）；
• 11:00 升级：加入自定义校验器 business_rules.py ，支持 minLength , enum_from_file 等；
• 13:00 实战测试：用会议纪要的 topic_schema.yaml 校验，成功捕获 topic_name 为空的错误；
• 14:00 加入重试逻辑：失败时，自动提取错误信息，生成新Prompt重试；
• 16:00 部署：把 schema_guard.py 放入 apds-core/ 目录，所有项目 from apds_core import SchemaGuard 。
• 17:00 体会： 模块化不是为了炫技，而是为了把“救火经验”变成“防火设施 ”。

4.5 Day 25：APDS全模块联调——当四个模块第一次协同作战

目标：在API文档生成器中，同时启用SchemaGuard、AuditAnchor、FactChecker、FormatContract。

• 09:00 配置 apds_config.yaml ，开启所有模块；
• 10:00 运行，首次失败： SchemaGuard 报错 "responses" field missing ——因为输入的OpenAPI YAML中，有个端点没写 responses ；
• 10:30 修复：在 SchemaGuard 中加 optional_fields: ["responses"] 配置；
• 11:00 继续， AuditAnchor 报错 anchor file not found ——因为 fact_checker.py 没生成 fact_check.json ；
• 11:30 调试：发现 fact_checker 的输入路径写错了，应为 ./input/openapi.yaml 而非 ./openapi.yaml ；
• 13:00 终于通过所有校验，生成文档；
• 14:00 FormatContract 报错： JSON code block indentation error at line 89 ；
• 14:30 自动修复成功，日志显示 Fixed json indentation ；
• 15:00 查看最终文档：标题层级正确、代码块高亮、链接有效。
• 16:00 总结： 联调不是一次成功，而是暴露所有模块间的隐含假设 。APDS的价值，正在于把这些假设显性化、可配置化。

4.6 Day 30：部署与反思——APDS不是终点，而是新起点

目标：把APDS打包成Pip包，供团队使用。

• 09:00 创建 setup.py ，定义 apds-core==0.3.1 ；
• 10:00