PRIMARY OUTPUT
一份核对过的租金月报
面向租客，包含正文和少量必要图表。
- 本期值得关注的变化
- 城市整体与行政区比较
- 几个生活圈的观察
- 租客可参考的预算差异
- 来源、统计时间与限制
保留 AI 初稿和修改稿，能看出人工改了什么。
RENTAL MARKET · AI ASSISTED REPORT
把行情数据
写成一份
有依据的报告。
用现有数据做一次小范围尝试。让 AI 帮忙整理、写稿，再由我核对，看看这条流程能不能跑通。
方案讨论中 · 尚未开始完整报告试验
1座城市数据检查后确定
1类月报先从一种租屋类型开始
＋换一个月份，再试一次确认模板能否继续使用
01
先看看，现有数据能写出什么。
目前数据主要用于查询和展示。把它写成报告，还需要找变化、组织内容和逐项核对。
我想以研发工程师的方式，把取数、计算、生成和检查串起来，先做出一份面向租客的内部报告。
数据够不够？月份、区域和样本是否支持比较。
报告能不能读？重要变化是否清楚，解释是否有依据。
下次还能不能用？换一期数据，哪些步骤仍要手工处理。
首轮由我自己完成。实际记录耗时和返工；提效比例、内容效果和运营认可，留待有对照或实际反馈后判断。
02
六步跑通，关键内容由我确认。
先用现有工具、文件和脚本做试验。每完成一步，就留下下一步需要的材料。
窄屏可在图内横向滚动查看完整流程。
FIG. 01人机分工与推进顺序。AI 和脚本辅助执行，人工负责范围与最终确认；复用时继续沿用检查步骤。
| 步骤 | 做完留下什么 | 这里容易出错 |
|---|---|---|
| 01 确定范围 | 城市、月份、类型及数据缺口 | 有月份记录，不代表当月已完整统计 |
| 02 整理数据 | SQL、查询结果、取数时间、字段说明 | 单月与近三个月滚动统计混用 |
| 03 计算变化 | 同比、环比、区域差异及事实编号 | 缺失、小样本或零分母被写成持平 |
| 04 生成初稿 | 正文、图表、重要结论的依据 | AI 为涨跌补写没有证据的原因 |
| 05 核对修订 | 修改稿、问题记录、内部审核状态 | 把 AI 的复查当作最终确认 |
| 06 换月复用 | 另一月份的试跑记录、模板及总结 | 只生成一次，就认定模板已经可复用 |
03
每个重要结论，都能查回数据。
能机械核对的交给脚本。自己重点看标题、主要结论和图表，AI 辅助检查遗漏。
FIG. 02结论、事实和查询结果之间的对应关系。
先确认比较的是同一种东西
挂牌开价与租约金额分开。当前期与比较期使用相同筛选条件，写清单位和统计时间。
没有数据，就保留空缺
小样本和缺失单独记录。报告门槛需明确，不能直接沿用页面的展示规则。
先写变化，再看能否解释
中位数上涨可能伴随房型或面积构成变化。没有证据时，不能直接归因于政策、交通或就业。
生活圈“热门”需要另一类依据
先确认历史浏览、收藏或联系数据。暂时没有，就做租金观察，并说明原 KR 的这一项仍未覆盖。
不知道的地方，
就明确写出来。
FIG. 03发现问题后的处理方式。修订后重新核对；无法确认时，缩小范围或暂缓，并记录未完成项。
“内部验证通过”表示完成本轮自查。内容是否适合正式发布，后续仍需要实际使用者确认。
04
留下报告，也留下下一次的做法。
文件集中保存即可，不需要为了试验写很多份长文。
DATA + SQL真实汇总数据、查询语句、口径和取数时间。
CHECKS + NOTES计算与检查脚本、发现的问题、修改和耗时记录。
TEMPLATE / SKILL先留一份可复用模板，步骤稳定后再封装 skill。
REVIEW已可用的部分、仍缺什么，以及下一次值得改哪里。
范围明确，数据缺口已说明
真实报告的重要结论可追溯
完成核对、修订和发布前自查
另一个历史月份已试跑
留下模板或 skill
总结结果，并说明 KR 未覆盖项
以上是待完成事项，不表示当前进度。生成一篇文章，并不等于整个 KR 已完成。
BEFORE WE START
执行时再定的几件事
城市与月份租屋类型历史数据范围样本门槛生活圈关注度数据
先看数据准备需要多少工作，再确定排期。生产查询和报告生成，等明确进入执行阶段后开展。
＋
需要细节时，展开完整计划。
原 Markdown 的八个章节完整保留在下方，图文总览没有替代其中的条件与限制。
1. 为什么想做这件事
目前已有一些租金行情数据，主要用于页面查询和展示。要把这些数据整理成月报、区域对比或推广内容，仍然需要人工取数、找变化、写说明和核对。
我想利用现有数据做一次尝试：让 AI 辅助整理行情信息，生成一份面向租客的报告，再由我检查和修改，看看这套做法能不能用起来。
这次先由我作为研发工程师完成，不把编辑同事参与作为开始的前提。先做出一份内部报告，把遇到的问题记下来，后续再判断是否适合交给运营使用。
这项尝试对应当前 KR 中的两项要求：
- 选择至少一类行情报告，基于真实数据完成 AI 辅助生成、人工校验和发布前审核流程验证。
- 沉淀一份可以继续使用的 skill 或报告模板。
2. 这次想弄清楚什么
首先要确认现有数据能支持哪些内容。比如，能否比较本月和上月的租金，能否看到行政区之间的差异，生活圈数据是否够用。
其次，看看 AI 能否根据这些数据写出一份基本可读的报告。除了把数字写进句子，还希望它能选出值得关注的变化，并把统计范围和限制说明白。
最后，实际体验一下从取数到检查完成需要做多少工作。记录哪些地方省事，哪些地方仍然需要反复核对，以及换一期数据后能否继续使用。
首轮暂不预设效率提升比例，也不以阅读量、点击率或转化率作为完成条件。这些需要人工对照或实际发布后才能判断。
3. 第一轮做多大
先做一座城市的一期租金月报。具体城市、月份和租屋类型，进入执行阶段后根据数据情况确定。
| 项目 | 第一轮的安排 |
|---|---|
| 读者 | 正在找房、希望了解租金和区域差异的租客 |
| 城市 | 一座，优先选择历史数据较齐全、区域样本较充足的城市 |
| 时间 | 优先选已结束的月份，并检查数据是否完成更新；不能只看月份字段判断完整性 |
| 租屋类型 | 先选一种，例如独立套房；顺利后再增加两房等类型 |
| 内容 | 城市租金变化、行政区差异、几个生活圈的情况 |
| 形式 | 一篇正文，配少量能说明问题的表格或图表 |
| 使用范围 | 内部试验和自审，完成后保留为待发布稿 |
季报、半年报、年报先作为后续方向。跨期统计需要重新确认取数和去重方式，不能直接把几个月的中位数平均后作为季度或年度中位数。
原 KR 中的“热门生活圈变化”也需要单独确认。浏览、收藏、联系等历史数据可能支持关注度分析；租金高或刊登量多，本身不能说明热门。若首轮无法取得合适的数据，就先做生活圈租金观察，并在总结中注明这一项尚未完成，不能把它直接算作原 KR 已满足。
4. 准备怎么做
第一步：确认能取到哪些数据
进入执行阶段后，由 AI 辅助通过 DBHub 对 production 做只读查询，优先使用现有行情汇总表。
先检查表结构、索引和必要的查询计划，再限制城市、时间和类型取数。首轮不需要导出房东、租客的个人信息，也不需要拉取全部房源明细。
重点看以下几件事：
- 候选城市有哪些月份的数据，是否存在缺月。
- 当前期、上期和去年同期是否都有相同类型的数据。
- 城市、行政区和生活圈的样本数量是否足够支持比较。
- 月度数据与近三个月滚动数据分别来自哪里，统计时间是否清楚。
- 数据什么时候更新，是否还会补算，是否能确认实际覆盖到哪一天。
表里存在某个月的记录，不代表该月已经完整统计。数据不足时先缩小范围，不为了凑齐报告内容补写数字或结论。
这一步完成后，确定第一份报告的城市、月份、租屋类型，以及暂时做不了的内容。
第二步：整理一份固定的数据
保存本次 SQL、取数时间和查询结果。后续写稿、画图和检查都使用这一份数据，避免处理中途数据更新，导致数字对不上。
不同查询可能发生在不同时间，需要保留各自的取数时间；不能默认它们属于同一个数据库快照。
数据至少包含月份、地区、租屋类型、租金指标和样本数。再附一份简短说明，写清楚：
- 租金是挂牌开价还是租约金额，使用什么单位。
- 数字表示单月情况，还是近三个月情况。
- 房型、面积等筛选条件是什么。
- 样本如何去重，缺失、零值和样本不足分别怎么处理。
这些说明可以从现有代码、字段和业务文档中整理。无法确认的地方单独记录，先不使用对应指标作结论。报告用的样本门槛也需要明确，不能直接照搬页面的展示门槛。
第三步：算出变化，整理成事实清单
用 SQL 或脚本计算同比、环比、区域差异和排名，把计算结果整理好后再交给 AI。
每条准备写进报告的发现，至少保留对象、时期、指标、样本数和来源。例如：某区域某类房源的租金中位数是多少，与上期相比变化多少，对应哪条汇总记录。
计算时检查当前期和比较期是否使用相同条件。比较期缺失、分母为零或样本不足时，标为不能比较，不写成持平。
先说明哪里发生了变化。有条件时再按房型、面积等继续拆开看，判断是否伴随样本构成变化。仅凭中位数上涨，不能认定同类房屋都涨价，也不能直接归因于政策、交通或就业变化。
第四步：让 AI 生成初稿
将事实清单、数据说明和固定的报告要求交给 AI，先生成一份初稿。
报告可以按下面的顺序组织：
- 本期值得关注的几项变化。
- 城市整体和行政区比较。
- 几个生活圈的观察。
- 对租客有参考价值的信息，例如不同区域的预算差异。
- 数据来源、统计时间和本期限制。
要求 AI 使用已核验的数字，并在内部稿中标注重要结论对应的数据编号。原因没有证据就不写，数据不足的部分可以省略并说明原因。面向租客的正文使用自然的繁体中文，避免夸张标题。
图表也使用同一份数据生成，标题和坐标轴注明地区、单位及统计时间。
第五步：核对、修改，再做一次发布前自查
我重点检查标题、主要结论和图表，并对照数据确认数字。能够机械检查的部分交给脚本，AI 可以辅助找出文字中的口径混用或推断问题。
| 检查内容 | 具体看什么 |
|---|---|
| 数字 | 金额、涨跌幅、排名和单位是否与数据一致 |
| 时间 | 单月与滚动统计是否混用，当前期和比较期是否写对 |
| 样本 | 缺失或小样本是否已说明，有没有被写成零或持平 |
| 解释 | 有没有把猜测写成原因，把挂牌租金写成成交租金 |
| 标题与图表 | 是否准确表达正文，是否夸大了局部变化 |
| 可读性 | 租客能否看懂，是否堆砌数字或使用空泛描述 |
记录发现的问题、修改内容和复核结果。AI 的第二轮检查可能仍会漏错，最后由我确认。
本轮的发布前审核以内部自查为主，检查完整后标记为“内部验证通过”或“待修订”。它不能证明内容已经得到运营认可，也不代表已经对外发布。
第六步：换一个月份再试
保留报告结构、提示词和检查方式，换一个历史月份重新生成。观察是否仍要大量手工调整，以及遇到缺失、小样本或明显变化时能否正确处理。
将能够复用的内容整理成报告模板。如果操作步骤已经稳定，再封装成 skill。首轮先用文件和脚本串起流程，是否需要定时任务、后台页面或自动发布，留到实际使用后再决定。
5. 我需要参与哪些事情
AI 可以辅助写 SQL、整理数据、编写计算和检查脚本、生成报告，并记录问题。我主要负责确认报告范围、核对关键口径和结论，判断结果是否值得继续做。
如果某个业务字段的含义从现有资料中无法确认，就先把问题记下来。可以跳过对应内容，也可以后续找熟悉该数据的同事确认，不要求我独自判断所有业务问题。
暂时没有编辑参与时，先把报告做到数据可查、内容可读、问题有记录。内容选题和对外表达是否合适，后续拿到实际使用者的反馈后再调整。
6. 预计留下哪些东西
| 内容 | 保存它的用途 |
|---|---|
| SQL、查询结果和数据说明 | 能重新取数，也能查清报告数字从哪里来 |
| 必要的计算和检查脚本 | 下次更换数据后可以继续使用 |
| 报告初稿和修改后的版本 | 能看出 AI 做了什么、人工改了什么 |
| 问题和耗时记录 | 找出最容易出错、最费时间的步骤 |
| 一份报告模板或 skill | 支持下一期重复生成 |
| 简短的试验总结 | 说明已经能用的部分、剩余问题和后续建议 |
不要求每项都单独写成长文。能放在同一个目录或记录表里的内容，就集中保存。
7. 做到什么程度算完成
首轮按以下事项检查：
- □ 已确定报告范围，并说明数据覆盖和缺口。
- □ 使用真实行情数据生成至少一份报告，重要数字和结论能够找到依据。
- □ 完成一次人工核对、修改和发布前自查，保留检查记录。
- □ 使用另一个历史月份试跑，记录模板复用时遇到的问题。
- □ 留下一份可继续使用的报告模板或 skill。
- □ 写出试验总结，并说明原 KR 中仍未覆盖的部分。
同时记录取数、核对、修改等环节的人工作业时间，以及运行失败和返工情况。首轮没有人工写稿的对照，因此只报告实际耗时，不计算未经验证的提效比例。
如果遇到数据不足或生成效果不佳，可以调整范围或暂缓。这样的结果也有参考价值，但需要写明没有完成哪些目标，不能把生成了一篇文章直接等同于整个 KR 完成。
8. 开始前还需要确定什么
目前需要在执行时进一步确定的事项包括：首选城市和月份、租屋类型、可用的历史范围、报告样本门槛，以及是否有生活圈关注度数据。
工具和模型可以先使用当前可用的方案，等出现具体限制后再调整。暂不承诺固定排期，先看数据准备需要多少工作。
本次只整理实施计划。后续生产查询、取数和报告生成，等明确进入执行阶段后再开展。