企业官网建设流程全解析

“这个月写了 12 次技术笔记、8 次阅读记录”，改写成“日日笔耕，读写相伴”很顺口，却把可核对的数量变成了另一种印象。生活手记可以有情绪，统计不能跟着情绪走。

适合自动化的做法是先计算，后表达。让程序得到稳定的事实对象，再请模型围绕这些事实写短文；不把计算任务和修辞任务揉成一次自由生成。

事实和感受各自有位置

金额、次数、日期范围、缺失值来自记录。疲惫、欣喜或“这个月更专注”属于感受，需要作者确认，不能从次数直接推导。两天没有记录，也不等于两天没有生活。

Ollama 的结构化输出文档说明可以传入 JSON schema，并在返回后验证。它适合约束“事实字段与文稿字段”的形状，但事实来源仍要由应用维护。官方文档

让统计先独立运行

保存为 journal.py。它使用合成记录，重复编号会被拒绝；输出总数不依赖模型的算术能力。

from collections import Counter from datetime import date rows = [ {"id": f"t{i}", "day": "2026-10-20", "kind": "技术"} for i in range(12) ] + [ {"id": f"r{i}", "day": "2026-10-21", "kind": "阅读"} for i in range(8) ] def summarize(records, start, end): seen, kinds = set(), Counter() for item in records: if item["id"] in seen: raise ValueError("记录编号重复") seen.add(item["id"]) day = date.fromisoformat(item["day"]) if start <= day < end: kinds[item["kind"]] += 1 return {"技术": kinds["技术"], "阅读": kinds["阅读"], "合计": sum(kinds.values())} facts = summarize(rows, date(2026, 10, 1), date(2026, 11, 1)) assert facts == {"技术": 12, "阅读": 8, "合计": 20} try: summarize(rows + rows[:1], date(2026, 10, 1), date(2026, 11, 1)) except ValueError: pass else: raise AssertionError("重复计数未拒绝") print(facts)

如果记录缺失，另列“缺失记录数未知”，不要用 0 代替。金额计算改用 Decimal 并保留币种；跨月活动也要预先约定归属规则。这些决定会改变统计口径，不能交给润色阶段临时猜。

一段不过度解释的改写

可写：“这份示例手账留下了 12 条技术笔记和 8 条阅读记录，共 20 条。它们记录了两种不同节奏：有些问题需要逐行验证，有些句子适合慢慢读。”

后一句是写作表达，不是对作者心理或工作效率的测量。“效率提高 70%”“焦虑显著减少”都需要另外的数据与方法，不能从这 20 条记录推出。

2026 年 10 月 20 日 IBM Research 的记忆工作流文章把能力与重复成功分开衡量；对写作工具也一样，偶尔保留一次数字并不等于长期可靠。原文

本文实跑了计数、日期范围和重复检测，没有调用模型，也没有真实月度生活数据。把数字留住之后，文字才有可以依靠的地面。