# AI 辅助租金行情报告生成探索计划

日期：2026 年 10 月 26 日  
当前阶段：方案讨论，尚未开始完整报告试验

## 1. 为什么想做这件事

目前已有一些租金行情数据，主要用于页面查询和展示。要把这些数据整理成月报、区域对比或推广内容，仍然需要人工取数、找变化、写说明和核对。

我想利用现有数据做一次尝试：让 AI 辅助整理行情信息，生成一份面向租客的报告，再由我检查和修改，看看这套做法能不能用起来。

这次先由我作为研发工程师完成，不把编辑同事参与作为开始的前提。先做出一份内部报告，把遇到的问题记下来，后续再判断是否适合交给运营使用。

这项尝试对应当前 KR 中的两项要求：

- 选择至少一类行情报告，基于真实数据完成 AI 辅助生成、人工校验和发布前审核流程验证。
- 沉淀一份可以继续使用的 skill 或报告模板。

## 2. 这次想弄清楚什么

首先要确认现有数据能支持哪些内容。比如，能否比较本月和上月的租金，能否看到行政区之间的差异，生活圈数据是否够用。

其次，看看 AI 能否根据这些数据写出一份基本可读的报告。除了把数字写进句子，还希望它能选出值得关注的变化，并把统计范围和限制说明白。

最后，实际体验一下从取数到检查完成需要做多少工作。记录哪些地方省事，哪些地方仍然需要反复核对，以及换一期数据后能否继续使用。

首轮暂不预设效率提升比例，也不以阅读量、点击率或转化率作为完成条件。这些需要人工对照或实际发布后才能判断。

## 3. 第一轮做多大

先做一座城市的一期租金月报。具体城市、月份和租屋类型，进入执行阶段后根据数据情况确定。

| 项目 | 第一轮的安排 |
| --- | --- |
| 读者 | 正在找房、希望了解租金和区域差异的租客 |
| 城市 | 一座，优先选择历史数据较齐全、区域样本较充足的城市 |
| 时间 | 优先选已结束的月份，并检查数据是否完成更新；不能只看月份字段判断完整性 |
| 租屋类型 | 先选一种，例如独立套房；顺利后再增加两房等类型 |
| 内容 | 城市租金变化、行政区差异、几个生活圈的情况 |
| 形式 | 一篇正文，配少量能说明问题的表格或图表 |
| 使用范围 | 内部试验和自审，完成后保留为待发布稿 |

季报、半年报、年报先作为后续方向。跨期统计需要重新确认取数和去重方式，不能直接把几个月的中位数平均后作为季度或年度中位数。

原 KR 中的“热门生活圈变化”也需要单独确认。浏览、收藏、联系等历史数据可能支持关注度分析；租金高或刊登量多，本身不能说明热门。若首轮无法取得合适的数据，就先做生活圈租金观察，并在总结中注明这一项尚未完成，不能把它直接算作原 KR 已满足。

## 4. 准备怎么做

### 第一步：确认能取到哪些数据

进入执行阶段后，由 AI 辅助通过 DBHub 对 production 做只读查询，优先使用现有行情汇总表。

先检查表结构、索引和必要的查询计划，再限制城市、时间和类型取数。首轮不需要导出房东、租客的个人信息，也不需要拉取全部房源明细。

重点看以下几件事：

- 候选城市有哪些月份的数据，是否存在缺月。
- 当前期、上期和去年同期是否都有相同类型的数据。
- 城市、行政区和生活圈的样本数量是否足够支持比较。
- 月度数据与近三个月滚动数据分别来自哪里，统计时间是否清楚。
- 数据什么时候更新，是否还会补算，是否能确认实际覆盖到哪一天。

表里存在某个月的记录，不代表该月已经完整统计。数据不足时先缩小范围，不为了凑齐报告内容补写数字或结论。

这一步完成后，确定第一份报告的城市、月份、租屋类型，以及暂时做不了的内容。

### 第二步：整理一份固定的数据

保存本次 SQL、取数时间和查询结果。后续写稿、画图和检查都使用这一份数据，避免处理中途数据更新，导致数字对不上。

不同查询可能发生在不同时间，需要保留各自的取数时间；不能默认它们属于同一个数据库快照。

数据至少包含月份、地区、租屋类型、租金指标和样本数。再附一份简短说明，写清楚：

- 租金是挂牌开价还是租约金额，使用什么单位。
- 数字表示单月情况，还是近三个月情况。
- 房型、面积等筛选条件是什么。
- 样本如何去重，缺失、零值和样本不足分别怎么处理。

这些说明可以从现有代码、字段和业务文档中整理。无法确认的地方单独记录，先不使用对应指标作结论。报告用的样本门槛也需要明确，不能直接照搬页面的展示门槛。

### 第三步：算出变化，整理成事实清单

用 SQL 或脚本计算同比、环比、区域差异和排名，把计算结果整理好后再交给 AI。

每条准备写进报告的发现，至少保留对象、时期、指标、样本数和来源。例如：某区域某类房源的租金中位数是多少，与上期相比变化多少，对应哪条汇总记录。

计算时检查当前期和比较期是否使用相同条件。比较期缺失、分母为零或样本不足时，标为不能比较，不写成持平。

先说明哪里发生了变化。有条件时再按房型、面积等继续拆开看，判断是否伴随样本构成变化。仅凭中位数上涨，不能认定同类房屋都涨价，也不能直接归因于政策、交通或就业变化。

### 第四步：让 AI 生成初稿

将事实清单、数据说明和固定的报告要求交给 AI，先生成一份初稿。

报告可以按下面的顺序组织：

1. 本期值得关注的几项变化。
2. 城市整体和行政区比较。
3. 几个生活圈的观察。
4. 对租客有参考价值的信息，例如不同区域的预算差异。
5. 数据来源、统计时间和本期限制。

要求 AI 使用已核验的数字，并在内部稿中标注重要结论对应的数据编号。原因没有证据就不写，数据不足的部分可以省略并说明原因。面向租客的正文使用自然的繁体中文，避免夸张标题。

图表也使用同一份数据生成，标题和坐标轴注明地区、单位及统计时间。

### 第五步：核对、修改，再做一次发布前自查

我重点检查标题、主要结论和图表，并对照数据确认数字。能够机械检查的部分交给脚本，AI 可以辅助找出文字中的口径混用或推断问题。

| 检查内容 | 具体看什么 |
| --- | --- |
| 数字 | 金额、涨跌幅、排名和单位是否与数据一致 |
| 时间 | 单月与滚动统计是否混用，当前期和比较期是否写对 |
| 样本 | 缺失或小样本是否已说明，有没有被写成零或持平 |
| 解释 | 有没有把猜测写成原因，把挂牌租金写成成交租金 |
| 标题与图表 | 是否准确表达正文，是否夸大了局部变化 |
| 可读性 | 租客能否看懂，是否堆砌数字或使用空泛描述 |

记录发现的问题、修改内容和复核结果。AI 的第二轮检查可能仍会漏错，最后由我确认。

本轮的发布前审核以内部自查为主，检查完整后标记为“内部验证通过”或“待修订”。它不能证明内容已经得到运营认可，也不代表已经对外发布。

### 第六步：换一个月份再试

保留报告结构、提示词和检查方式，换一个历史月份重新生成。观察是否仍要大量手工调整，以及遇到缺失、小样本或明显变化时能否正确处理。

将能够复用的内容整理成报告模板。如果操作步骤已经稳定，再封装成 skill。首轮先用文件和脚本串起流程，是否需要定时任务、后台页面或自动发布，留到实际使用后再决定。

## 5. 我需要参与哪些事情

AI 可以辅助写 SQL、整理数据、编写计算和检查脚本、生成报告，并记录问题。我主要负责确认报告范围、核对关键口径和结论，判断结果是否值得继续做。

如果某个业务字段的含义从现有资料中无法确认，就先把问题记下来。可以跳过对应内容，也可以后续找熟悉该数据的同事确认，不要求我独自判断所有业务问题。

暂时没有编辑参与时，先把报告做到数据可查、内容可读、问题有记录。内容选题和对外表达是否合适，后续拿到实际使用者的反馈后再调整。

## 6. 预计留下哪些东西

| 内容 | 保存它的用途 |
| --- | --- |
| SQL、查询结果和数据说明 | 能重新取数，也能查清报告数字从哪里来 |
| 必要的计算和检查脚本 | 下次更换数据后可以继续使用 |
| 报告初稿和修改后的版本 | 能看出 AI 做了什么、人工改了什么 |
| 问题和耗时记录 | 找出最容易出错、最费时间的步骤 |
| 一份报告模板或 skill | 支持下一期重复生成 |
| 简短的试验总结 | 说明已经能用的部分、剩余问题和后续建议 |

不要求每项都单独写成长文。能放在同一个目录或记录表里的内容，就集中保存。

## 7. 做到什么程度算完成

首轮按以下事项检查：

- [ ] 已确定报告范围，并说明数据覆盖和缺口。
- [ ] 使用真实行情数据生成至少一份报告，重要数字和结论能够找到依据。
- [ ] 完成一次人工核对、修改和发布前自查，保留检查记录。
- [ ] 使用另一个历史月份试跑，记录模板复用时遇到的问题。
- [ ] 留下一份可继续使用的报告模板或 skill。
- [ ] 写出试验总结，并说明原 KR 中仍未覆盖的部分。

同时记录取数、核对、修改等环节的人工作业时间，以及运行失败和返工情况。首轮没有人工写稿的对照，因此只报告实际耗时，不计算未经验证的提效比例。

如果遇到数据不足或生成效果不佳，可以调整范围或暂缓。这样的结果也有参考价值，但需要写明没有完成哪些目标，不能把生成了一篇文章直接等同于整个 KR 完成。

## 8. 开始前还需要确定什么

目前需要在执行时进一步确定的事项包括：首选城市和月份、租屋类型、可用的历史范围、报告样本门槛，以及是否有生活圈关注度数据。

工具和模型可以先使用当前可用的方案，等出现具体限制后再调整。暂不承诺固定排期，先看数据准备需要多少工作。

本次只整理实施计划。后续生产查询、取数和报告生成，等明确进入执行阶段后再开展。