开发日志，一半是写给自己的，一半是写给别人的。

做新东西的路上，你会学新技能、犯新错误、做新决定。卡到半夜的那个晚上、为一个小 bug 磨掉的几个小时——过几年回头看，你多半全忘了。日志替你记着这些，别人也能从里面学到东西。

没有日志，别人就无从知道：你是怎么把它拼起来的？为什么选 A 不选 B？哪怕只写一小段，也能让人看见你思考和踩坑的过程。

我们也靠它来核验。你提交后，核验会看你的日志，确认三件事：你的决定说得通、东西是你自己做的、过程真实存在。

---

怎么写

好日志是一个故事——你的故事。

不需要完美的中文或语法，写清楚就行。别让 AI 替你写日志：它不知道你的故事，只会写出一篇正确但空洞、一眼假的流水账。你用 ys log new 建一篇，或者用 ys log "..." 快发一条，都行——关键是里面装的是你自己的经历。

每完成一天的活、或者到了一个小节点，就写一篇。

1. 讲清为什么，别只报流水账

一篇日志最重要的，是讲清为什么，不只是做了什么。三个问题答上来就够了：

• 你做了什么？
• 你为什么这么做？
• 你遇到了什么问题？

2. 多截图、多拍照

别等做完、做好看了才截图——每个有意义的步骤都留一张，中间乱糟糟的样子也要，「修好之前」和「修好之后」的对比更要。做硬件就多拍实物照。

3. 踩了坑就老实写

你一定会犯错：游戏里主角穿墙了、接线接反了、外壳打印出来差了两毫米。把它们写下来，再写你怎么修的。一篇没有任何错误的日志，是说明书，不是日志。

---

一句话总结

---

对比一下

❌ 不好：

我加了个稳压模块，接好线。做了 CAD，加了外壳。全部焊到一起，然后它就能用了！

问题在哪：

• 你为什么要加稳压模块？
• 外壳是干嘛的？有什么特别的设计吗？
• 你怎么测试确认「它能用了」的？
• 这段话换成任何一个项目都成立——它没告诉我你具体做了什么。

✅ 好：

6 月 8 日：屏幕终于亮了！！

总算让主板在这块 LCD 上显示出画面了，简直不敢相信真的成了。

我一开始参照的是某个开源项目的接线，但它用的屏和我手上这块驱动芯片不一样。所以我不光要搞懂它原来怎么点亮屏幕，还得把那套方法改成适配我这块屏的驱动。

（配图：接线中途的照片）

卡了很久的地方是：我不确定系统里到底有没有我这块屏需要的驱动。后来我顺着几个仓库一路翻源码，才确认驱动是存在的——就是要在配置文件里改对参数。下面是我最后跑通的配置……

看出区别了吗？好的那篇让你跟着他的思路走了一遍：他撞到什么墙、怎么绕过去、最后怎么成的。这才是日志。

---

写好 README、记好日志，你的项目就站得住了。万一被退回，核验反馈会告诉你缺什么，规则见核验规则。