当AI成为我们日常工作的紧密伙伴时，如果我们一天的工作都和AI结对干活，我们就可以让帮我们写工作日志了。
这是一个每天必做的的重复工作，AI了解我们的所有工作内容，工作日志的格式是我们可以明确定义的，LLM要做的 任务就是对当天的聊天记录进行归纳整理。于是我们可以写一个Skill来完成这个工作：
name: "Daily-worklog"
description: "根据每天的聊天日志整理出结构化工作日志。当用户提到'工作日志'、'编写日志'、'每日日志'、'今日总结'等字眼时触发。"
Daily Worklog -每日工作日志
根据当前会话的聊天记录，整理并输出一份结构化的工作日志。
触发条件
当用户消息中包含以下关键词时自动触发：
- "工作日志"
- "编写日志"
- "每日日志"
- "今日总结"
- "干活日志"
- "worklog"
输出格式
按以下六个部分整理输出：
1. AI做了哪些事情？
列出本次会话中AI完成的所有工作项，按时间/逻辑顺序排列。每项应简洁明确，说明做了什么、涉及哪些文件/功能。
2. AI做对了什么？
总结AI表现良好的方面，包括：
- 正确理解用户需求的实例
- 技术方案选择合理的地方
- 高效解决问题的案例
- 代码质量好的方面
3. AI做错了什么？
诚实记录AI的失误，包括：
- 理解偏差或方向错误
- 技术方案失败的情况
- 引入的bug或问题
- 低效的尝试路径
4.后续AI应该怎么做？
基于经验教训，提出AI后续工作的改进方向：
- 应该优先尝试的技术方案
- 应该遵循的工作流程
- 应该避免的陷阱
5.后续AI不能做什么？
明确列出AI不应该做的事情：
- 不应重蹈覆辙的错误路径
- 不应使用的技术方案
- 不应浪费时间的尝试
6.对人有哪些改进建议？
向用户提出协作层面的建议：
- 需求描述可以更清晰的地方
- 可以提供的关键信息
- 可以优化的反馈方式
- 环境/工具层面的建议
注意事项
- 日志应基于当前会话的完整聊天记录
- 要诚实、客观，不要美化AI的表现
- 输出直接呈现，无需额外解释
- 如果当前会话较短（少于5轮对话），可以适当精简
案例：
工作日志- 2026年6月11日
当日任务
- HTML转PDF Skill开发：将 starry-slides 生成的 PPT 转 PDF，处理滚动截屏分页问题
- MDD Toolkit自动填充工具- B27宏触发Bug修复：程序触发宏后E列全部变成"t"，手工操作正常
一、AI做了哪些事情
1. HTML转PDF Skill开发
- 将PPT HTML文件转换为PDF
- 处理溢出页面的滚动截屏分页问题（第38-39页）
- 将转换流程封装为可复用的Skill，写入 .trae/skills/html2pdf/
2. MDD Toolkit Bug修复（核心任务，耗时最长）
- 使用oletools提取 .xlsm 文件中VBA源码（/tmp/vba_full_dump.txt）
- 分析VBA宏逻辑：Config_Level_Change、Config_Domains、Config_PA_Target、Config_Project_Num
- 多次迭代修改 api/mddFillingEngine.js：
- 排查TCC权限问题（macOS沙盒）
- 尝试openpyxl方案（放弃，因破坏VBA）
- 调整单元格写入顺序（B27 vs B28-B35）
- 尝试force trigger机制（先写''再写真值）
- 尝试显式写C27值，清除C27公式
- 最终破局：用openpyxl读取C27公式 =MID(B27,7,1)
- 修复方案：添加格式转换映射表，将 "Maturity Level 5" 转换为 "Level 5 (Optimizing)"
- 重启后端服务（node api/index.js，端口3001）和前端（npm run dev，端口5173）
- 验证修复结果：E10-E26显示正确的数字5
3.博文撰写
- 撰写技术博文《第7个字符的陷阱》，总结本次调试全过程
- 保存至 blog-excel-automation.md
二、AI做对了什么
- 系统性分析VBA代码：提取VBA源码后，正确识别了四个宏的逻辑，发现所有宏都读取 $C$27（而非 $B$27）
- 发现了中间态现象：用户观察到"先变成5，后变成t"，AI正确推断发生了两次宏触发
- 使用外部工具突破Excel限制：C27单元格被Excel锁定不可见，用openpyxl的 data_only=False 成功读取到公式定义
- 最终根因定位准确：=MID(B27,7,1) 公式要求B27第7个字符是数字，"Maturity Level 5" 的第7位是 "t"
- 修复方案简洁正确：格式映射表方案直接解决根因，而非打补丁
- HTML转PDF Skill成功创建：独立任务完成良好
三、AI做错了什么
- 初始定位偏差，走了多个弯路：
- 误判为TCC权限问题（实际是AI沙盒的权限问题，非用户环境）
- 误判为openpyxl方案可行（会被坏VBA宏代码）
- 误判为写入顺序问题（手工操作顺序无关也能正常工作）
- 误判为force trigger中间态问题（治标不治本）
- 误判为公式被覆盖需清除（跟根本原因无关）
- 未尽早检查C27的公式定义：这是最关键的失误。在知道"所有宏都读 $C$27"之后，应该第一时间去读取C27的公式，而不是反复尝试各种workaround。如果第二轮就检查公式，后续的调试都可以跳过。
- "想当然"的错误：默认认为 "Maturity Level 5" 和 "Level 5" 是等价的，没有验证数据验证下拉菜单的实际值格式。
- 对数据验证的忽视：数据验证下拉菜单中的值格式（"Level 5 (Optimizing)"）与程序写入的格式（"Maturity Level 5"）不一致，这个差异没有在早期被识别。
- 服务重启失误：尝试用 node server.js 启动（文件不存在），而非正确的 npm run dev 和 node api/index.js
四、后续AI应该怎么做
遇到宏结果异常时，优先排查公式依赖链：
- 第一步：用 openpyxl(data_only=False) 读取所有相关单元格的公式定义
- 第二步：对比手工操作和程序写入时，每个下游公式的输入值差异
- 第三步：确认数据验证下拉菜单中允许的值格式
手工正常但程序异常时，优先对比"写入的值"：
- 手工操作通过下拉菜单选择了什么值？
- 程序写入了什么值？
- 两者是否真的等价？（字符串格式、空格、大小写等）
使用openpyxl先读再写：
- 在操作目标文件之前，先用openpyxl读取关键单元格的公式、数据验证规则，建立完整的"契约清单"
- 将契约清单作为调试参考
遵守调试原则：
- 先理解数据流，再修改代码
- 避免猜测式debugging（反复尝试不同方案碰运气）
- 一个假设被否定了，分析为什么错了再提出下一个
格式转换应前置设计：
- 在开发填充逻辑时，就应该建立"输入数据 ↔ 目标数据格式"的映射
- 不应在调试阶段才意识格式转换的必要性
五、后续AI不能做什么
- 不能想当然地假设字符串等价：未经验证的情况下，不能认定两个"看起来差不多"的字符串在Excel公式中是等价的
- 不能对问题的根因做猜测式判断：在缺乏足够证据时，不应贸然实施修改方案。应先收集充分证据再行动
- 不能忽视Excel的保护/锁定机制：被锁定的单元格往往是关键数据，应主动使用工具绕过UI限制查看其内容
- 不能反复修改代码而不先验证假设：每一轮修改应有明确的可验证假设，验证失败后应分析原因再进入下一轮
- 不能用workaround掩盖根因：force trigger、显式写C27、清除公式都是绕过根因的补丁，不应作为正式方案
- 不能在没有用户确认的情况下替换技术方案：如从JXA切换到openpyxl，应考虑用户对原方案已投入的工作
六、对人有哪些改进建议
- 评估输入表的数据格式定义：
- 建议在评估输入表中明确标注：B32（目标等级）的填写格式是什么
- 或者直接修改评估输入表，使其填写的格式与目标表的数据验证一致
- Excel模板的维护文档：
- 建议整理一份文档，列出MDD Toolkit中各关键单元格的：
- 数据验证规则（允许的值）
- 公式定义
- 宏的触发条件和数据依赖
- 这份文档将成为未来自动化开发和调试的重要参考
- 自动化测试用例：
- 建议为填充引擎建立端到端测试
- 测试用例应覆盖：不同等级（1-5）、不同领域组合、不同项目数量
- 每个用例验证E列的值是否正确
- 目标文件的版本管理：
- 建议将"干净版本"的目的文件单独保存并标记版本
- 每次测试前自动复制干净版本，避免手工恢复
- 调试时的信息可见性：
- 建议临时解除C27等关键单元格的锁定/保护，方便观察公式和值
- 或者在调试时用openpyxl查看所有关键单元格的实际值和公式
- 格式契约的显式化：
- B27的约束"第7个字符是数字"是一个隐式接口约束
- 建议在代码中或文档中显式记录这类约束，避免未来的开发者重蹈覆辙
当日成果
项目 | 状态 |
HTML转PDF Skill | 已完成 |
B27宏触发Bug修复 | 已修复并验证 |
技术博客 | 已完成初稿 |
VBA源码提取 | 已完成 |
