I'm FC

背景（2026/4/20）

很久没有写文章了，最近公司的事情暂时交付了，得以闲下来做一些思考。

近一年以来，因为AI技术的发展，从生产方式到生产内容，都有了很大的变化，各行各业都会受到了冲击。去年刚入职的时候，公司没人用ai，cursor刚出来，GPT版本还是3.5。我用ai开发了.ai官网并带着实现了一些meet官网的活动页面以后，老大终于发现ai技术的潜力了，毕竟同样的活儿，我一个人可以干，安卓那边要2个人，还没我快。等到他自己用了下以后发现不对劲了，开始买会员全公司推广了。说实话我只是想着有好东西大家一起用，但是最终好像是以一己之力带动了公司的ai改革。后来在组内做了前端ai使用经验和技术分享，制定了前端的项目规范agent.md以及用ai开发的场景和边界。到上个月，据说有同事一天干了1个亿的token，我估计是没有加ignore，但是在用就是好事。

地址

网址：六爻算命

原理

先整理六爻的原理，将六爻摇挂的交互，抽象成6次抛硬币，对应6个结果映射为6个卦象，然后封装提示词给ai分析，准的可怕，老祖宗的智慧真的不懂但是需要尊重。

从 0 到 1 做一个「迪士尼周边交易小程序」：AWW 技术复盘

关键词：微信小程序、Spring Boot、PostgreSQL、JWT、Flyway、腾讯云 COS、运营后台、性能优化

1. 背景与目标

AWW（爱上迪/爱上海迪）是一个面向迪士尼周边爱好者的交易与社区平台，产品形态上由三部分组成：

• 小程序端（aww-web）：面向普通用户的主入口，包含发现/论坛/图鉴/我的、商品详情与发布、私聊、发售日历等。
• 后端服务（aww-server）：统一的 REST API，承载登录鉴权、商品与交易数据、论坛与聊天、文件上传、埋点与运营统计等。
• 管理后台（aww-dashboard）：面向运营/管理员，用于管理 SPU/SKU、上传资源、审核/下架交易信息、管理用户与配置、查看埋点汇总。

背景

一直做各种奇奇怪怪的梦，每次解梦挺麻烦的，所以我就想做一个解梦、存梦罐子，记录下所有的梦。不得不说对于理解她的潜意识，理解当前的心境，真的很有帮助。

网址：光怪陆离的梦

原理

本质上也就是定制了一个提示词作为解梦agent啦

背景

706群里有一个飞书表格收集了大家去过的好吃的美食，包括店名、价格、特色、美食地址等。

刚好比较嫌就花了一天利用ai实现了一下，直接在 lovable 发布

最近进入了一个旅游群，发了一下不知道是否有人用

网址：美食地图

复盘

1. UI还是需要人设计
2. 需要找愿意用的人再做，这个做出来一直没人用，挺浪费的

背景

柯布生态学院是一个国际教育组织，专注于推广其教育理念，提倡教育的目的不应只是服务人类，更要融合生态理念，实现人类的可持续发展。

从黄山打完黑客松回来以后，朋友推荐的一个活儿，因为是类似公益网站，没啥钱并且需要降低维护成本，本来打算用express的但是考虑到后面做品牌升级，加上还有个管理后台，可能要定制。

所以最后经过调研，用react框架结合supabase数据库实现了整个网站。然后通过vercel进行部署，实现了0成本部署，后续假设用户数量大迁移加钱也方便，并且也不算贵。

网址：柯布生态学院

单页应用（SPA）因其动态加载特性，在SEO上面临内容索引困难、页面结构不清晰等问题。本文基于动态渲染、结构化数据优化、URL设计等关键技术，结合实际案例，提供一套完整的SPA SEO优化方案，并探讨如何在搜索结果中触发Sitelinks（子链接）的展示。

---

一、SPA SEO优化的核心挑战

1. 动态内容不可见
   SPA依赖JavaScript动态渲染内容，传统爬虫可能无法执行JS，导致页面内容无法被索引。
2. URL结构扁平化
   前端路由生成的虚拟URL（如哈希路由#/page）缺乏独立性，难以被搜索引擎识别为独立页面。
3. 元数据缺失
   动态生成的<title>和<meta>标签可能未被爬虫捕获，影响搜索结果展示效果。

大前端技术路线

应用程序性能监控（APM）和埋点（Instrumentation）虽然都涉及数据采集和分析，但它们的核心目标、实现方式和使用场景有显著差异。以下是详细的对比和解释：

---

1. 定义与核心目标

• APM（Application Performance Monitoring）
  专注于技术层面的性能监控，目的是实时追踪应用的健康状态，发现性能瓶颈（如响应延迟、服务器负载、数据库查询效率等），确保系统稳定运行。

  • 典型场景：诊断服务器CPU飙高、API接口超时、内存泄漏等问题。

• 埋点（Instrumentation）
  专注于业务和用户行为的数据采集，目的是通过代码插入追踪逻辑，收集用户交互数据（如按钮点击、页面跳转、功能使用频率等），用于业务分析和产品优化。

  • 典型场景：分析用户购买流程中的流失点，或评估新功能的使用率。

背景

因为电费均摊不公和不透明，以及计算麻烦等问题，每次水电都算起来很麻烦，但是每次计算的规则其实是一致的，故写了个简单的页面处理下

工具：Cursor

提示词：

帮我写一个网页，index.html就好，用来计算电费均摊结果的，

1. 已知一共五个房间合租，楼下3个（三个表），楼上2个（共用一个表），一共四个电表（假设分别叫ele_1,ele_2,ele_3,ele_4），假设房间分别叫楼下A，楼下B，楼下C，楼上D，楼上E，房间与电表对应关系如下： 楼下A - ele_1 楼下B - ele_2 楼下C - ele_3 楼上D，楼上E - ele_4
2. 支持输入上个月抄表的数据（从左往右依次是ele_1,ele_2,ele_3,ele_4）
3. 支持输入本月抄表的数据（从左往右依次是ele_1,ele_2,ele_3,ele_4）
4. 支持输入本月总电费，精确到小数点后一位
5. 上海民电参考如下（2023年参考）： 一档（年用电≤3120度）：0.617元/度 二档（3121-4800度）：0.667元/度 三档（＞4800度）：0.917元/度