AI 辅助开发「休历」项目复盘总结

本文提取自 Abo’s Blog 的《AI辅助开发-休历》，原文记录了作者用 AI 辅助完成「休历」这个个人工具的过程。它不是单纯炫技，而是一次从真实需求出发，把模糊想法拆成可执行产品功能，再反复修改、补齐数据能力、打包交付的完整小项目复盘。

一句话总结

作者想解决请假记录、出勤统计、工资扣除、节假日出行提醒这些日常问题，于是借助 Chat、Claude、Codex 等 AI 工具，把一个最初比较粗糙的想法逐步做成了「休历」：一款面向打工人的出勤、请假、出行、工资记录工具。

项目起点

需求来自很具体的工作场景：小公司请假流程不够规范，很多时候只是口头或微信说明，请假条和记录容易缺失。作者希望做一个工具，能够根据日期和原因生成请假条，并顺手管理请假天数、出勤天数、工资扣除、年假调休额度、节假日购票提醒等信息。

这个起点很关键：它不是为了“用 AI 写个项目”而写项目，而是先有痛点，再让 AI 参与实现。

从粗糙提示词到结构化需求

作者一开始给 AI 的提示词比较口语化，像是在描述“我想要一个月历、统计请假、算工资、提醒买票、生成请假条”。随后通过 Chat 优化，把需求拆成更清晰的功能模块：

  • 月历视图：展示公历、农历、节假日、周末、调休等信息。
  • 请假统计：支持按月、按年统计事假、病假、总请假天数、实际出勤天数等。
  • 工资计算：按月薪、应出勤天数、请假天数、固定扣除金额计算实际收入。
  • 购票提醒：基于节假日和“火车票提前 15 天开售”的规则生成提醒。
  • 请假条生成：根据请假类型、日期、天数、理由生成正式模板。
  • 数据管理：支持 localStorage 本地保存，以及 CSV 导入导出。

这一步体现了 AI 辅助开发里非常重要的一点：提示词不是一句话魔法，而是把产品需求结构化的过程。

第一版的问题

通过 Claude 和 Codex 生成的第一版已经能跑起来，但作者认为 UI 的“AI 味”较重，不符合自己想要的极简风格。后续主要进入不断修改、微调、重构的阶段。

作者也提到，用中文描述有时难以让 AI 精准理解审美和交互意图，改用英文沟通后效果有所提升，但仍需要反复打磨。这说明 AI 能快速给出可用初稿，却未必能一次命中个人化的产品气质。

真正的难点：数据完整性

后续开发中，作者发现最大问题不是界面，而是节假日、节气等信息不完整。因为这些数据不完整，购票提醒、出勤判断、工资计算等功能就很难完善。

为了解决这个问题，作者调研并接入了 Chinese Days API，用它补足中国节假日相关信息。这一步让项目从“静态页面工具”更接近真实可用的应用：界面可以靠 AI 快速生成，但关键数据源仍然需要认真选择和验证。

继续优化与交付

在 UI 优化阶段，作者从 GPT5.5 切换到 Claude Fable 5，并对页面继续迭代。最终项目不仅有了更满意的界面，还构建了 PWA、Portable 版本和可执行安装 exe，完成度进一步提升。

项目最后的定位也变得更清晰：休历是一款用于记录出勤、请假、出行、工资等信息的打工人工具。

这篇文章给我的启发

第一，AI 很适合把粗糙想法快速变成原型，但原型之后的方向判断仍然需要人来掌舵。没有清晰目标时，AI 容易做很多看似努力、实际无效的改动。

第二，真实项目不是只有代码。节假日 API、数据结构、导入导出、离线保存、打包交付，这些“工程边角”才决定工具能不能长期用。

第三，提示词优化的本质不是写得更华丽，而是让需求更可执行。把功能、状态、输入、输出、交互和边界条件列清楚，AI 的产出质量会明显提高。

第四，做自己真正需要的工具会更容易坚持。因为每一次修改都能对应到真实使用场景，而不是为了完成一个抽象 demo。

可借鉴的实践清单

  • 先写真实使用场景，再让 AI 帮你拆功能。
  • 第一版先求能跑，别一开始就追求完美。
  • UI 不满意时，不只说“好看一点”，要描述风格、密度、颜色、布局和参考对象。
  • 涉及节假日、价格、政策、时间等可变数据时，尽早找可靠数据源。
  • 对 AI 的每次修改都要验收，不要让它无目标地连续改。
  • 当工具对自己确实有用时，可以继续补 PWA、桌面版、导入导出等交付能力。

相关链接与来源