AI实战之小程序07-说说树洞举报导航怎么落地，我这样补齐社区扩展

SourceLin

398人浏览 · 2026-06-11 21:57:12

SourceLin · 2026-06-11 21:57:12 发布

阅读和用户资产补齐之后，小程序还缺最后一层“有理由再回来”的内容氛围。很多项目做到这一步就停了，社区 Tab 还是空的，树洞只是个想法，举报入口没有，友链导航关于也只是以后再说，结果小程序看起来像个内容壳，没有社区感，也没有站点感。

Sourcelin 这轮把“社区扩展”单独收口，就是为了把说说、树洞、举报、友链、导航、关于这些看似分散的能力，真正变成一组能被用户感知到的轻社区入口。

本次阶段推文基于产品文档、仓库现状和本地可提取开发记录生成，未完整依赖远端会话历史。

这个阶段为什么不能只做一个社区列表

产品文档 5.1 第 6 周把这一阶段定义为：

说说基础互动
树洞
举报入口
友链
导航
关于

这几个点如果分开看，像是零散补功能；但从移动端体验看，它们其实都在回答一个问题：用户除了读文章，还能不能感知到这个站点在“活着”。

当前对应的页面和能力已经补齐

社区页：sourcelin-ui/sourcelin-ui-uniapp/src/pages/community/community.vue
说说发布：sourcelin-ui/sourcelin-ui-uniapp/src/pages-publish/say/say.vue
树洞投递：sourcelin-ui/sourcelin-ui-uniapp/src/pages-publish/treehole/treehole.vue
关于页：sourcelin-ui/sourcelin-ui-uniapp/src/pages-about/index/index.vue
友情链接：sourcelin-ui/sourcelin-ui-uniapp/src/pages-about/links/links.vue
网站导航：sourcelin-ui/sourcelin-ui-uniapp/src/pages-about/navigation/navigation.vue
社区 API：src/modules/community/api/community.api.ts
举报 API：src/modules/report/api/report.api.ts
埋点 API：src/modules/analytics/api/analytics.api.ts
后端补充：sourcelin-modules/sourcelin-blog/src/main/java/com/sourcelin/blog/controller/front/FrontReportController.java、FrontAnalyticsController.java

到这里已经能看出，这一阶段不是只写前端页面，而是把前端动作和后端接口一起补上了。

社区页已经不是占位，而是说说和树洞双列表

社区页现在直接承接两类内容：

const result = activeTab.value === 'says'
  ? await fetchSayPage(targetPage, 10)
  : await fetchTreeholePage(targetPage, 10);

这个结构的好处很直接：

说说和树洞都能在一个一级 Tab 里承接
每个列表都有分页、互动和空态
发布入口会根据当前 Tab 自动切到“发说说”或“写树洞”

更重要的是，社区页里的点赞、收藏、评论抽屉和举报都已经接入真实动作，不再是浏览壳。

树洞投递这次真正补到了产品要求的细节

产品文档对树洞要求里有一个很容易被忽略的点：失败或中断后，草稿要本地暂存 1 小时。

这次树洞页正好把这个细节做进去了：

const DRAFT_KEY = 'publish.treehole.draft';

setStorage(DRAFT_KEY, {
  nickname: nickname.value.trim(),
  avatar: avatar.value.trim(),
  content: value
}, 3600);

这段代码的价值，比单纯“能发树洞”更大。因为它说明小程序已经开始按真实用户操作来做体验，而不是只顾着把接口调通。

举报、导航、关于、友链都已经从占位变成真实入口

社区扩展最容易被拖延的，往往就是举报和站点信息，因为这些功能不够炫，但缺了以后体验很假。

现在举报链路已经接到后端：

export function createContentReport(payload: ContentReportPayload): Promise<void> {
  return http.post<void>('/front/reports', payload);
}

后端也补了对外 Controller：

@RestController
@RequestMapping("/front/reports")
public class FrontReportController extends BaseController
{
    @PostMapping
    public Void create(@Valid @RequestBody FrontContentReportDTO body)

友情链接、导航和关于页也都不再是“建设中”，而是已经能拉数据、筛选、复制链接和提交申请。尤其导航页，已经补了分类切换和关键词筛选，这比只展示一页静态列表更像真实站点入口。

为什么我现在确认“社区扩展”可以勾选完成

之前这一阶段不能勾，原因非常明确：

树洞投递还没闭环
导航、关于等页面还有占位
社区页还不足以形成访问理由

这次复核后，这几个阻断点都已经不在了：

社区 Tab 已具备说说/树洞双列表
树洞匿名投递支持 1 小时草稿暂存
举报入口已经接入前后端
友链、导航、关于全部有真实内容与交互

按产品文档第 7 章“只有核心页面、核心交互、占位替换和验收项全部闭合才算完成”的口径，这一阶段已经满足勾选条件，所以我会把它转为已完成，并补上这篇统一长文。

社区扩展完成状态图

以下是社区扩展各模块的完成状态可视化，展示了从"占位"到"真实功能"的转变：

效果图

社区-说说

开发过程提示词（优化版）

请先读取 AGENTS.md、rules/frontend-uniapp.md、rules/api-contract.md，
以及 docs/product/UNIAPP_MINI_PROGRAM_PRODUCT_DESIGN.md 第 5.1 节“社区扩展”阶段要求。

本次只处理社区扩展，不扩展到兼容与性能、联调验收或后台管理能力。

请重点补齐：
1. 社区页说说/树洞双列表与基础互动
2. 树洞匿名投递与 1 小时草稿暂存
3. 举报入口及前后端接口
4. 友链、导航、关于真实页面与内容入口

输出时必须说明：
1. 页面目录与 API 归属
2. 哪些占位已被替换
3. 哪些后端接口是新补的
4. 当前还缺哪些上线前验证