之前申请写过小作文，可惜是没通过，现在终于有机会进来了，很喜欢这里的氛围，以后应该会经常来了 11 个帖子 - 11 位参与者 阅读完整话题
佬友们好，今日鄙人有幸加入到组织中来了，之前写过小作文但石沉大海，今天靠着11年的GitHub账号终于是如愿了，哈哈哈哈，开心，留贴 1 个帖子 - 1 位参与者 阅读完整话题
之前写过写过两次小作文都没过。这次10多年的github号终于免小作文加入佬友们了。 23 个帖子 - 18 位参与者 阅读完整话题
最近在用agent写量化策略，发现效果不是很好，将qmt平台的文档蒸馏后使用ai写，回测也成功但想修改小细节比如加入真实持仓又无法回测 13 个帖子 - 6 位参与者 阅读完整话题
之前看过一本书叫小狗钱钱，看完突然觉得书中介绍的方法感觉很不错，比如说梦想存储罐，成功日记，金鹅账户，然后看完想跟着书里的方法写成功日记试试，但是发现没有类似的软件，于是乎自己灵机一动干脆自己来写一个，如果用的人多了可以加个广告赚点米，结果兴致冲冲花了几天写完尝试在小红书推广，结果小红书根本不怎么给曝光，就算有浏览也没人用，现在只有13个用户，并且这些用户只是登录一下坚持写了一两天的日记就没消息了，只有一个人坚持了四十天，但最近她也不写了，不用我这个了，哎，说实话，现在我自己都懒得写 10 个帖子 - 5 位参与者 阅读完整话题
有人用 codex app 写过 flutter 吗，最近 vibe 一个小工具时候总是遇到执行 flutter 命令卡死情况 还有 test 这些也是，明明就是一个小命令。 很奇怪，前几个月也用过好像没出现。 特别是我这种小工具一半直接设置个goal就走了，结果发现卡在这好难受 1 个帖子 - 1 位参与者 阅读完整话题
有佬写过阿里云百炼coding plan的购买脚本吗？ 公司报销要买一个来着，同事好几天都抢不到！！！ 1 个帖子 - 1 位参与者 阅读完整话题
【实践分享】25年到26年，我的NL2SQL智能体是如何迭代的 前言 之前写过一篇《如何手搓一个RAG》，当时主要讲的是知识库问答。 引流： https://linux.do/t/topic/2187051 这篇讲另一个更痛苦的东西：NL2SQL。 先叠甲： 我不是底层模型开发，也不是论文选手，我是AI应用开发，现在人们叫 AI应用落地工程师 （有点想补一个黄豆流汗）。 这篇不讲特别高大上的理论，主要讲我自己从老项目到新项目的工程迭代。 里面很多东西可能现在看起来很土，很笨，很原始。 因为很多东西不是一开始就长成现在这个样子的。 现在大家都很懂智能体、tool call、workflow、planner、memory、MCP，但我第一次认真把这套东西串起来的时候，企业应用里还没有这么成熟的说法。那时候更多叫机器人、助手、问答系统，或者更朴素一点：大模型接口外面套一圈业务逻辑。 先说时间线 老项目是一个早期业务问答助手，这里就不写真实项目名了。 下面会附上老项目的git记录，其实实际时间比git更早，但有git记录就已经能说明老了。 老项目的Java服务模块最早能追到： 2025-08-04 11:00:49 早期数据问答基线上传 Python智能问答模块也是同一天开始： 2025-08-04 11:00:49 早期数据问答基线上传 然后到了2025-08-14，提交记录里已经出现了这种东西： 意图识别时校验问题中的数据表是否存在 生成SQL时判断问题中的字段是否存在 生成SQL提示词优化，增加自校验逻辑 SQL执行错误给出友好提示 再到2025-08-19，又有： 报表问答准确率提升：修改生成SQL提示词结构，采用少样本提示的标准写法 也就是说，至少在2025年8月，这个东西已经不是“我接个模型接口玩一下”了，而是在认真处理意图识别、表识别、字段校验、SQL生成、错误兜底这些问题。 新项目是2026年重做的一套业务智能体系统。 它的项目初始化是： 2026-04-20 14:45:08 项目初始化 数据问答正式落到新项目里，是： 2026-04-23 15:44:44 新增数据问答前后端能力并完成会话链路语义解析接口与数据库表落库 所以这篇讲的不是“我最近看agent火了，赶紧包装一个概念”。 更准确地说，是： 我在智能体概念还没有被企业应用完全标准化的时候，先用一种很土的方式把它做出来了；然后到2026年，我又把这套土办法重新工程化了一遍。 老数据问答：先把链路跑通 老数据问答主要看两个部分： Java服务模块 Python智能问答模块 虽然用户入口、会话记录、前后端接口在Java应用里，但真正干NL2SQL脏活累活的是Python侧的问答模块。 当时的链路大概是这样： 用户提问 -> 问题重写 -> 意图识别 -> 判断要查哪张表 -> 权限校验 -> 拼表结构和few-shot样例 -> 让大模型生成SQL -> 从模型返回里抠出SQL -> 执行SQL -> 让大模型总结结果 -> 如果用户要图表，再让大模型生成Echarts配置 -> 流式返回给前端 现在看起来，这不就是一个智能体么？ 有意图识别，有工具选择，有工具执行，有结果加工，有流式输出，甚至还有图表工具。 但当时我不会这么说。 我只会说：这是数据问答。 或者说得更土一点：这是一个会查数据库的机器人。 问题重写 老链路里第一步就是问题重写。 这个东西在知识问答里重要，在NL2SQL里更重要。 因为用户不会每次都把问题说完整。 比如： 第一轮：今年杭州有多少商机？ 第二轮：按行业分一下 如果第二轮直接拿去生成SQL，大模型可能知道“按行业分一下”是什么意思，也可能不知道。它不知道的时候，就开始表演了。 所谓表演，就是一本正经地胡说八道。 所以老项目里先把历史问题压缩成当前独立问题。这个思路没错，到现在也没错。 只是当时实现比较朴素：把最近几轮对话塞进提示词，让模型判断要不要改写。能用，但依赖模型稳定性。 意图识别 老项目里有一个很典型的东西：函数式意图识别。 它会让模型返回类似这样的结构： { "function_call": { "name": "search_sql", "arguments": { "table": "项目表", "char": "柱状图" } } } 这其实已经很接近现在大家说的tool call了。 只不过那个时候不是标准工具协议，也不是框架自动帮你做。就是自己写提示词，自己解析JSON，自己判断 name 是什么，自己决定下一步走哪里。 有人会问了，这不就是手搓function calling么？ 是的。 很土，但能跑。 SQL生成 老链路真正刺激的地方是SQL生成。每次演示就好像上战场一样。 当时的思路很直接： 根据用户问题识别要查哪张表。 找到这张表的字段说明和相似问法。 把表结构、字段含义、few-shot样例、SQL生成规则一起塞给模型。 让模型返回SQL。 程序再把SQL抠出来执行。 这里的核心其实是few-shot。 例如“今年杭州新签约合同数量是多少”这种问题，对人来说很简单，对模型来说不一定简单。因为它要知道： “今年”对应哪个时间字段。 “新签约”对应哪个状态或日期。 “杭州”对应城市字段，而且可能还要处理“杭州市”“杭州分公司”这种说法。 “数量”是 count ，不是把某个金额字段求和。 所以当时靠大量样例去教模型。 这条路是有效的。 但它有一个问题：越做越像补丁。 你发现“城市”识别不准，就加城市规则。 你发现“字段不存在”会乱生成，就加字段存在性校验。 你发现SQL报错太难看，就包装友好提示。 你发现用户想看图，就让模型再生成Echarts配置。 你发现“省、市、区县”容易混，就再写一个地名修正。 最后系统当然能跑，而且效果还可以。但你心里知道，这东西有点像用胶带把飞机粘起来。 飞是能飞。 但每次上线都要默念一句：千万别问奇怪问题。 老在哪里 这里我要强调一下，“老”不是贬义。 很多老办法在当时就是正确答案。 因为业务要结果，用户要能用，领导要演示，项目要交付。你不可能坐在那里说：等我设计一个完美语义层，半年后再说。 不现实。 老项目确实就是有很明显的时代痕迹。 第一，模型直接生成SQL 老链路里，模型承担的任务太重了。 它不仅要理解用户问题，还要理解表结构，还要选择字段，还要生成SQL，还要自己判断字段是否存在。 这就像让一个实习生同时当产品经理、数据库工程师、测试和客服。 他有时候很聪明，有时候也真的离谱。 最简单的例子：字段名。 你给他一张表，里面有“合同金额”“签约金额”“中标金额”“预算金额”。用户问“金额是多少”，他到底该用哪个？ 如果业务口径稳定，模型可能猜对。 如果业务口径不稳定，模型猜对了也只是运气。 第二，提示词越来越长 为了让模型不犯错，我们会不断往提示词里加规则。 不能 select * 。 日期要怎么转换。 城市要去后缀。 字段别名不能当查询条件的值。 枚举值模型不能自己发明。 SQL生成前后要判断字段是否存在。 SQL生成后再自检一下字段是否存在。 听起来很严谨，对吧？ 但提示词不是法律。 提示词更像劝告。 你说了一百条规则，模型不一定真的每条都遵守。特别是表结构一长、样例一多、用户问题一复杂，它就开始挑自己记得住的部分执行。 这就是老链路让人很痛苦地方。 第三，解析靠字符串和正则 老项目里会从模型返回中提取JSON、提取SQL、提取Echarts配置。 这也是当时很常见的做法。 模型返回： ```sql select ... from ... ``` 我们就用正则把他抠出来。 模型返回： ```json {"sql": "select ..."} ``` 我们就转JSON。 问题是，模型有时候会多说一句“好的，以下是SQL”。 也有时候会少一个引号。 也有时候会把中文标点、代码块、换行混在一起。 然后你就开始写各种清洗逻辑。 写到最后，你都分不清自己是在做NL2SQL，还是在做大模型输出垃圾回收。 第四，安全边界后置 老链路也做了不少安全处理，比如权限校验、表名校验、SQL错误兜底、结果数量限制。 但整体上，它还是先让模型生成SQL，再在后面拦。 这个顺序在生产里会带来心理压力。 因为模型生成SQL这件事本身就是不稳定的。 你可以拦掉 delete 、 update 、 drop ，也可以限制只查某些表，但只要SQL是模型自由生成的，它就总有一些奇怪路径。 比如字段错了。 比如条件错了。 比如时间字段错了。 比如聚合口径错了。 这些不一定是安全事故，但一定是业务事故。 用户不一定知道SQL错了，他只会觉得你的机器人在胡言乱语。 第五，业务口径藏在提示词里 这是我后来最深的感受。 NL2SQL最难的不是SQL。 是业务口径。 “今年新增项目数”到底按创建时间、立项时间、签约时间，还是入库时间？ “中标金额”用预算金额、中标公告金额，还是合同签约金额？ “商机数量”算草稿、已发布、已中标，还是全部？ 这些东西不应该藏在提示词里。 因为提示词不适合承载业务制度。 提示词适合表达任务，业务口径应该进配置、进表、进规则、进校验的结构。 这也是我从老项目走到新项目，最大的变化。 新数据问答：从让模型写SQL，到让模型填语义 新项目是一套面向具体业务场景的智能体系统。 这时候它已经不再是单点机器人，而是一个统一入口。 知识问答、数据问答、首页意图识别、知识库管理、快捷问题，都在一个体系里。 数据问答这块，新链路大概是这样： 用户提问 -> 会话上下文补全 -> 大模型解析结构化语义 -> 后端规则兜底与合并 -> 指标/维度/别名/口径匹配 -> 判断是否需要澄清或确认 -> 构建统一语义对象 -> 校验语义对象 -> 后端生成受控SQL -> PreparedStatement执行 -> 构建指标卡片、表格、趋势、明细预览 -> 记录意图、语义、SQL、参数、结果行数 -> 流式返回前端 注意这里最关键的变化： 模型不再直接生成SQL。 模型做的是语义解析。 它只能基于后端给出的候选列表，选择指标、维度、过滤条件、时间规则、分析类型。 也就是说，模型从“写SQL的人”，变成了“帮用户填表的人”。 这一步非常关键。 四表语义层 新项目里数据问答有四张核心配置表： DQ_METRIC DQ_DIM DQ_ALIAS DQ_METRIC_VER 可以把它们理解成四层： METRIC：用户要查什么指标 DIM：用户按什么过滤、按什么分组 ALIAS：用户自然语言怎么映射到系统编码 METRIC_VER：同一个指标有哪些业务口径 举个例子。 用户问： 近30天中标商机数量是多少？ 老链路可能会让模型直接生成： select count(*) from 某张表 where ... 新链路会先变成一个语义对象： 指标：商机数量 口径：中标 时间：近30天 分析类型：summary 过滤条件：无 然后后端再根据配置生成SQL。 这样做的好处是，SQL不再是模型凭空写出来的。 它是业务配置推导出来的。 指标和口径分开 老项目里，“项目数量”“新增项目数量”“中标项目数量”“已签约项目数量”这些东西，很多时候会混在提示词和样例里。 新项目里，我更倾向于拆开： 指标：项目数量 口径：新增/中标/已签约/履约中 这看起来只是表设计变化，但实际影响很大。 因为用户说“数量”的时候，他可能问的是同一个指标；用户说“新增”“中标”“已签约”的时候，他问的是不同业务口径。 如果把这些都交给模型猜，模型迟早会猜错。 如果放到 METRIC_VER 里，就能让口径变成可维护的配置。 用户问得不清楚时，系统还能反问。 这比胡乱给一个答案要好得多。 别名是NL2SQL的命门 我后来越来越觉得，NL2SQL不是“自然语言转SQL”。 更准确地说，它是： 自然语言里的业务说法，映射到数据库里的结构化对象。 这里最麻烦的是别名。 用户不会按数据库字段名说话。 用户会说： 中标 赢单 签了 集团客户 客户经理 近一月 这个月 本季度 这些东西都得落到系统能识别的编码。 所以新项目里有 DQ_ALIAS 。 它不只是锦上添花，而是可用性的核心。 如果别名配得差，用户就会觉得机器人笨。 如果别名配得好，用户会觉得系统“懂业务”。 但其实不是模型突然变聪明了，是我们把业务语言铺好了。 时间必须有硬性规则 NL2SQL里时间非常容易翻车。 “今年”“本月”“近30天”“2024年”“2024年1月到3月”，看起来都是时间，但实际处理方式完全不一样。 老项目里很多时间规则是靠提示词和样例。 新项目里，我更愿意让后端规则优先。 比如代码里会先解析显式日期： 2024年 2024-01-01到2024-03-31 再处理“今年”“本月”“近30天”这种相对时间。 而且新链路会要求必须有时间范围，不允许直接扫全量。 有人会说：这是不是太保守了？ 是的。 但数据问答不是闲聊。你扫全量，那完蛋，到时候追责第一个找你。 交互和确认 老链路更像“一问一答”。 用户问，系统尽量答。 答不了，就报错或者提示重新描述。 新链路里，我加入了交互和确认。 比如用户问： 今年金额是多少？ 系统不应该硬猜“金额”是预算金额、中标金额、合同金额还是投资金额。 而是与用户产生交互，并提问： 你想查询的是预算金额、中标金额，还是合同金额？ 这就是从“机器人努力回答”变成“系统控制风险”。 我以前也会觉得，反问是不是显得机器人不够聪明？ 后来发现不是。 真正成熟的系统，应该知道什么时候不能瞎答。 受控SQL 新项目里SQL是后端构建的。 它基于语义对象拼： select from where group by order by 而且参数走 PreparedStatement 。 同时还有几条硬性边界： 只允许 SELECT 。 拒绝 DELETE/UPDATE/INSERT/MERGE/ALTER/DROP/TRUNCATE 。 必须有来源宽表。 必须有指标字段。 必须有时间字段和时间范围。 当前只支持单表宽表查询。 这就从根上改变了系统性质。 老项目是“模型生成SQL，程序尽量拦”。 新项目是“模型生成语义，程序决定SQL”。 一个是让模型开车，人在副驾驶踩刹车。 一个是人把轨道铺好，模型只负责把乘客放到正确车厢。 两代方案的本质区别 如果只看功能，两代数据问答都能做到： 用户自然语言提问。 系统查数据库。 返回总结。 必要时展示图表或表格。 但本质区别很大。 老方案：提示词工程驱动 老方案的核心资产是： 表结构说明。 few-shot样例。 SQL生成规则。 错误兜底逻辑。 一堆经验补丁。 它的优点是快。 一张表给出去，写一些样例，很快就能跑。 它的缺点也很明显： 表越多，提示词越膨胀。 字段越多，模型越容易选错。 口径越复杂，样例越难覆盖。 安全边界偏后置。 线上效果高度依赖模型稳定性。 所以老方案很适合从0到1。 它解决的是“有没有”。 新方案：语义层驱动 新方案的核心资产是： 指标配置。 维度配置。 别名配置。 口径配置。 后端SQL构建器。 可校验的意图、语义、SQL日志。 它的优点是稳。 因为大模型不再直接碰SQL。 它的缺点是慢。 不是运行慢，是建设慢。 你要先梳理指标、维度、别名、口径。你要问业务方：这个字段到底怎么算？这个“新增”到底按哪个日期？这个“中标”到底按哪个状态？ 这时候你会发现，NL2SQL不是技术问题。 它会把业务系统里所有没讲清楚的口径问题，全部挖出来。 这个过程很痛苦，但这是好事。 因为以前这些问题也存在，只是藏在Excel、口头约定和老员工经验里。 现在你要让机器回答，就必须把它们写下来。 为什么说这是智能体迭代 有人可能会说：你这不就是NL2SQL么，为什么叫智能体？ 我的理解是这样的： 如果只是： 用户问题 -> 大模型 -> SQL 那它确实只是NL2SQL。 但真实项目不是这样。 真实项目里要做： 上下文处理 意图识别 工具选择 权限判断 语义解析 SQL构建 SQL校验 数据库执行 结果解释 图表展示 日志校验 澄清确认 错误兜底 这些东西组合起来，就已经是一个面向业务目标的智能体链路了。 只不过老项目里，它是“土法智能体”。 新项目里，它开始变成“工程化智能体”。 老项目像这样： 模型很强，我写提示词让它尽量别乱来。 新项目像这样： 模型很强，但我只让它做适合它做的部分。 这是我的变化。 模型擅长理解自然语言、匹配候选、补全表达。 程序擅长执行规则、校验边界、生成稳定SQL。 让模型做模型擅长的事，让程序做程序擅长的事。 这就是我这一年最大的工程体感。 我踩过的几个坑 1.不要迷信“让模型自己想” 大模型很聪明，但生产系统不能靠聪明活着。 特别是数据问答。 知识问答答错了，用户还能去原文里看依据。 数据问答答错了，用户可能直接拿去汇报。 这就很吓人。 候选列表、配置边界、SQL模板、参数化执行，这些东西都要上。 2.不要把业务口径写死在提示词里 提示词里的规则很容易丢。 今天你改了一句提示词，明天结果变了，你很难解释到底变在哪里。 业务口径最好进表。 这样至少能回答： 这个指标叫什么。 它用哪张表。 它聚合哪个字段。 它默认带什么过滤条件。 它有哪些口径版本。 它支持哪些维度。 这才像一个能长期维护的系统。 3.不要觉得交互很丢人 很多时候，系统反问不是因为它笨，而是因为问题本身不完整。 用户说“金额”，但系统里有十种金额。 用户说“项目”，但系统里有建设项目、ICT项目、商机转项目、合同关联项目。 你硬答一个，看起来很流畅，其实是在赌。 赌赢了，用户夸你智能。 赌输了，用户说你乱讲。 4.训练样例还是有用，但位置变了 新方案不是不要样例。 样例依旧有用。 只是样例不应该承担全部。 老方案里，样例像发动机。 新方案里，样例更像校准器。 它用来补一些复杂问法、明细查询、模糊检索、TopN、范围比较，而不是让系统所有能力都靠样例撑着。 5.前端展示不是小事 NL2SQL的终点不是SQL。 甚至不是数据库结果。 终点是用户能不能看懂。 老项目里会让模型总结结果，也会生成Echarts。 新项目里更强调结构化返回：指标卡片、表格、趋势、明细预览。 用户问“今年有多少”，你给他一个单值就够了。 用户问“按城市分布”，你给他表格或柱状图。 用户问“近30天趋势”，你给他时间序列。 不要把所有结果都塞成一段大模型作文。 大模型作文看起来很像人，但业务人员要的是可核对、可复制、可追问。 总结 回头看这两代数据问答，我觉得自己的思路经历了三个阶段。 第一阶段： 让模型帮我写SQL。 这是最直觉的NL2SQL。 用户问一句，模型写SQL，程序执行，模型总结。 很爽，但爽完一塌糊涂。 第二阶段： 让模型在规则里写SQL。 加表结构、加样例、加字段校验、加权限、加错误兜底。 这时候系统已经能用了，但维护成本会越来越高。 第三阶段： 让模型只负责语义，SQL由系统生成。 指标、维度、别名、口径进配置。 模型做自然语言理解。 后端做校验和执行。 系统输出可审计结果。 这才是我现在更认可的方向。 当然，这不是说新方案完美。 它依旧有很多限制，比如当前更适合结构化聚合查询，更适合单表宽表，更依赖业务侧把指标维度梳理清楚。复杂关联查询、自由明细检索、长文本条件、跨域分析，后面还是要继续补。 但它至少从“能跑”走向了“能管”。 对企业应用来说，这个变化比炫技重要。 最后说一句很真实的话： 如果你现在想做NL2SQL，不要一上来就问模型选哪个。 先问自己： 你的业务指标清楚吗？ 你的字段含义清楚吗？ 你的时间口径清楚吗？ 你的枚举值和别名清楚吗？ 你的结果能校验吗？ 这些问题没想清楚，大模型越聪明，系统可能越危险。 因为它会把一个不清楚的业务，包装成一个看起来很清楚的答案。 这才是NL2SQL最可怕的地方。 很菜，别骂。 这就是我从2025年的早期数据问答助手，到2026年的新版数据问答系统，关于数据问答和NL2SQL的一点实践复盘。 先发后改。 2 个帖子 - 2 位参与者 阅读完整话题
求助！平时没怎么写过文章，今天急需写一下类似于软文或者檄文，用哪家ai比较好啊各位佬儿，Gemini吗 3 个帖子 - 2 位参与者 阅读完整话题
从来没用Gemini写过代码，一直在嫖反重力里的Claude，今天看到佬友说新的Flash很牛逼就试了一下，确实速度很吓人啊，但是这个一惊一乍的性格，真的能干严肃的活吗…… 19 个帖子 - 18 位参与者 阅读完整话题
想问问写过ai小说的各位佬们，昨天开始鼓弄ai小说，最后用cc写了一本书刚签约了，但是不知道有什么用，难道签约只是入门吗，流量之类的还是没有 才上传3w字，是不是写多一些才会有流量 3 个帖子 - 3 位参与者 阅读完整话题
来公司已经快两年了，没涨过工资，想调薪70%，大家觉得可以不，另外调薪申请请问该怎么写才合适啊？ 14 个帖子 - 14 位参与者 阅读完整话题
属虎的，年满40了，985硕士毕业（本科是二本院校），写过代码（java及vue），做过产品经理，做过管理CTO。比较内向，爱专研技术，但是现在AI时代来临了，公司优化人员严重，特别卷，感觉时刻会失业，危机感还是些许有的，不知道各位大龄佬友们有没有好的出路？ 15 个帖子 - 13 位参与者 阅读完整话题
之前写过一篇 【岛主】花了五万退掉房子之后，想和佬友们聊聊现在的买房逻辑 但总觉得强度不够，再出一篇买房相关的想法，后面回归 L 站初心分享 AI，不再水这类帖子了 上一篇帖子简单写了退房经历和经验教训，这里再补充一点，当时我买的那套房可以说“非常之划算”，退出来后被下家直接秒掉了（据说要靠拼手速的），作为新房准现房，甚至比现在挂出来的二手还便宜，别人还了三年贷款终于盼来交房，我买到手下个月就能新房入住，买价还是别人的八五折。 而且我的安全垫算比较厚，我老婆在体制单位，我俩其中任意一人的公积金就可以完全覆盖房贷还有多，理财一分没动，手上也留足了现金流，如果后面几年收入 all in 大概五六年就可以还清，这种情况如果在网上问起来应该也算妥妥可以放心冲的类型。 但我非常真诚想给各位佬分享一下我那段时间的心路历程，事实上我也不算什么特例，这是无数人经历过的，毕竟太阳底下无新鲜事。 1、贷款最大的影响，在于对心态的变化 在这样下行期大多数买房人的画像是，前期左右摇摆，买的时候咬咬牙一跺脚，买完之后，坐在房子里会经常有瞬间感到巨大的当房奴的空虚和恐惧，经常有点后悔，但每规划起装修又重新开始幸福，一直到入住之后逐渐和解，开始感受到房子给你带来的家的幸福。 我曾经也以为，这是找到一套房子的意义的过程，但现在我可能觉得，我自以为是和自己达成了和解，实则是“ 贷款负债已经完成了对我的思想驯化 ”。 现阶段当我们聊起买房，主流声音还是在各种算钱，算月供如何，算房价走势如何，但我自己的切肤感受是，意义最重大的依然是贷款这件事情对人的心态影响。 你接下来五年起步的首要目标只有一个：勒紧裤腰带，缩衣节食，早点把房贷还完。而这恰恰是你本可以无限试错无限进步的黄金时代。 这些话我以前在网上当乐子看过很多，但真正一发生，贷款一做，各种消费欲瞬时就像寒气一样席卷全身凝固住了。 哪怕账上有足够的现金流，哪怕老婆能兜底，哪怕家人能兜底。至少我会老老实实给自己拴上绳套，给自己加思想钢印，“我必须得早点还完”。 你会发现，以前所有任何的消费，瞬间索然无味，应砍尽砍。 你很难再有干的不爽就辞职的勇气，你对裁员的恐惧会无比加深放大，你对于听到 AI 替代谁谁谁的焦虑会几何放大，你对于换工作换城市会无比敏感抗拒却无能为力。 你的这几年不再被允许会有“停下来”这个按钮，你不会有几个连续的白天时间可以选择不上班，可以坐在家里或者出去随便溜达转转，思考自己想过怎样的人生，思考下我该怎么寻找内心的平静。 当房子退掉的那一刻，我感受到的是无比巨大的解脱感和安心感，一直到现在。 我一直有个朴素的个人哲学，当一件事情靠我的大脑已经分不清好坏利弊的时候，那么 如果我感受到的是快乐 ，那么它就是对的，感情，买房，各种地方都如此。 我也很感恩，有一个机会给我交不多的学费在有房和没房之间短暂地横跳了一回，人生最大的错配就是无法同时拥有两种感受，不上车自然也无法有真正的感同身受，而一套房子的购入与卖出，实在是太过于麻烦了。 所以我这些话主要想说给的是和我类似或者比我更加保守的佬友，我自己算是一个对于性价比比较看重但也不算抠搜的人，对于喜欢的贵重的东西，比如一两万的相机和镜头，在充分比过价确保能相对底部买到之后我都能比较爽快的买来悦己。几万块的旅行只要值得我一定会好好深入体验。 佬们可以自我审视一下，就平时买东西的消费观，对于借贷占比的态度，从而倒推贷款买房的态度。如果佬在资产观念上比我更保守，那么我刚才说的贷款体验，大概不会比我更好，与诸君分享。 2、啥是刚需？啥是刚需？啥是刚需？ 发明出“刚需”的人是绝顶聪明的，这个词把每个情况各异的人统一划到笼统概念里，不断异化，最后变成：要相亲是刚需，要结婚是刚需，结了婚也是刚需，生了娃更是刚需。 而且成功完成了对大家买房观念的教育，无数人谈论起买房，脑子里第一个词就是“刚需”，然后留下句“刚需就买”。 我觉得干脆再进一步，直接说：没买房就是刚需，然后在三段论推演一下，翻译过来就是，“没有房你就该买个房”（演都不演了 ）。 在我看来只有三种刚需： A、你需要用这套房去换取一段“你认为值得”的伴侣关系，这套房是最基本的谈判筹码 B、娃这几年就要上顶级一梯队学区，且需要提前占位，如果不买学区你就浑身难受，觉得对不起娃对不起自己（学区概念已经加速崩塌，这两年是最后需求旺盛的窗口） C、扪心自问之后可以笃定说出，我无比热爱人生的安稳感，任房价与时代变化的惊涛骇浪，我可岿然不动，一套房子是我最踏实的港湾。那么你可以在任何时候下手 3、背上贷款，你终于变成了一个“正经过日子的人” 这是站在上一代大多数长辈角度，父母把给孩子办完贷款作为使命的完成，长舒一口气。 我第一次产生“买这套房买错了”，是因为我母亲在电话里苦口婆心说：“买了房之后就日子过紧点，把钱看重一点，不要像之前一样去外面玩乱花钱。” 去年底和弟弟花了两万去埃及完了十几天，今年本来计划要去日本，但买这套房之后，这些应短期都不太可能了，如果说敢放开点有大额消费，意义好像也变成了劳累生活里的“犒赏”。 另外一个点，佬友们买房很多是需要家里资助的，很多时候这笔钱并不是白给的，有所予伴随着有所求，求的是结婚和生娃，买房图的是给你拧上发条第一步 各位佬不管在人生哪个阶段，请在不滑向极端消费主义的前提之下，不要忘记自己好一点。 4、假如房子现在就原地暴涨，那我就该买吗？ 佬们不要误会我是个房子的看空党之类，房价也说不定已近触底，一线城市年底直接反弹起飞，谁也说不准，我想表达的是 认清该不该买房，和房价要涨要跌，关系似乎并没多大。 哪怕从现在开始房价一飞冲天，你背上房贷一个月还是雷打不动要还那么多钱（甚至利率给涨点还要多还哈哈）。 现在很多人劝不要买，其实还是基于房价要下跌的预判。但事实上刚需首套你也不可能会短期轻易卖掉。基于自住房不考虑涨跌这个逻辑，是涨是跌其实都不那么重要了。 现在房价下跌的时候，大家的自我安慰逻辑是自住不亏，那么涨的时候也理所当然是自住不赚了。 所以问题依然指向：我该不该买，我是否需要这笔消费行为，而不该受到任何噪音干扰而导致动作变形。 5、不买房去租房，那不还是要付房租 买房分成两类，要么是高杠杆买房，这个我就不提了，不理解但尊重，现在应该几乎很少佬会这么选择，要么是低杠杆买房，对于手上这笔宽裕现金流，大可以努力学习理财，把收益率目标定在百分之三以上（对应商贷的 3.05%），把用理财收益跑赢房租作为你的阶段性理财学习目标。不管最后结果如何，理财也是佬友们受益终生的必修课 当然如果依然坚持要把房子当成不动资产来看，咱们的商品房历史也才三十多年，首先扪心自问下小区的物业水平，再结合过去看看那些已经经历二十年的鸽子笼变成了啥样子，当然这里面不乏很多优质房产，但在大部分佬面临的刚需首套前是很难成立的（况且 19 到 23 之间交付的房子很多佬应该明白是有目共睹的差）。 6、 关于租房想多说点 禁止将租房过度苦难化哈哈，如果有那么多的苦难，可能还是你的心态不到位。 如果觉得租房太苦涩，可以勇敢搬去那些房价你想都不敢想的地方的周边，找空房，找房东自住装修的房，可以大胆勇敢地给你的小窝添置家具，洗烘机，洗碗机，扫地机。 很多人对于自己的家还有个很经典的理论是，有家才会好好装修。他们说的装修有相当一部分是指那些打死的定制柜，把宝贵的面积拿去给一辈子钉死不动的柜子，佬友们可以先看看自己究竟倾向定制柜还是装修风格，如果不喜欢定制装修而是成品家具，那么一个你租来的小窝，和买来的小窝，其实已经并不会相差太多。 所谓的搬家的痛苦，每年只需要花几百块钱请个师傅就能解决。当然，如果连自己打包都嫌麻烦的话，一点手也不想动，佬可以了解下日式搬家哈哈。 结语： 依然还是想反复表达下：请把贷款买房认定是一场彻头彻尾的“ 借钱提前消费行为 ”。 当你认为这笔消费的价值回归到你所对等付出的真金白银的时候，就是应该入场的时候。 在 L 站，经常看到会有佬分享人生的迷茫，收入不高，感觉一事无成等等。 但比起前几年在房子上爆仓几年白干的朋友，躺着就是胜利，不折腾就跑赢一半的人。 请大家坚定相信，我们每个没有负债的个体，其实都享受了一个巨大的红利，就是在房价深度下跌的今天，被迫深度反思买房的本质，倒推又去思考结婚，思考生育，让一切跑的不那么疯狂，而不是像上涨期的病态，不问价，不问原因，就是满仓，就是干。 时代给了大家一次巨大的反思和认清自己的机会，佬友们请一定好好抓住。 请诸君共勉～ 4 个帖子 - 3 位参与者 阅读完整话题
20 年没有写过架空武侠小说了，前段时间一时兴起开始动笔。还以为写作能力退化了，没想到写得非常顺畅，于是拉来 AI 帮忙校对，分析，出主意，越写越嗨，一下子写了七八章。没想到几天后查了一下，竟然消耗了 4000 万 token ，花了 40 多美金。哎，嗨过头了，接下来就收敛了很多，不是每写一段就 run 一遍检查的 skill ，而是好好写完一章再一次性检查，需要 AI 查阅上下文的时候不允许 AI 调取正文部分，只准调取总结出来的内容的 summary （字数少很多），这样一下子减少了四五倍的使用量。 如果真要一直写下去，不知道还要花多少钱...我的程序员 partner 开玩笑说给我充个 500 块进去让我随便用。我说，你搞笑吧，你当 500 块是人民币啊，说充就充。 哈哈，哎，这年头，想要写点什么出来也是不容易啊。
20 年没有写过架空武侠小说了，前段时间一时兴起开始动笔。还以为写作能力退化了，没想到写得非常顺畅，于是拉来 AI 帮忙校对，分析，出主意，越写越嗨，一下子写了七八章。没想到几天后查了一下，竟然消耗了 4000 万 token ，花了 40 多美金。哎，嗨过头了，接下来就收敛了很多，不是每写一段就 run 一遍检查的 skill ，而是好好写完一章再一次性检查，需要 AI 查阅上下文的时候不允许 AI 调取正文部分，只准调取总结出来的内容的 summary （字数少很多），这样一下子减少了四五倍的使用量。 如果真要一直写下去，不知道还要花多少钱...我的程序员 partner 开玩笑说给我充个 500 块进去让我随便用。我说，你搞笑吧，你当 500 块是人民币啊，说充就充。 哈哈，哎，这年头，想要写点什么出来也是不容易啊。
20 年没有写过架空武侠小说了，前段时间一时兴起开始动笔。还以为写作能力退化了，没想到写得非常顺畅，于是拉来 AI 帮忙校对，分析，出主意，越写越嗨，一下子写了七八章。没想到几天后查了一下，竟然消耗了 4000 万 token ，花了 40 多美金。哎，嗨过头了，接下来就收敛了很多，不是每写一段就 run 一遍检查的 skill ，而是好好写完一章再一次性检查，需要 AI 查阅上下文的时候不允许 AI 调取正文部分，只准调取总结出来的内容的 summary （字数少很多），这样一下子减少了四五倍的使用量。 如果真要一直写下去，不知道还要花多少钱...我的程序员 partner 开玩笑说给我充个 500 块进去让我随便用。我说，你搞笑吧，你当 500 块是人民币啊，说充就充。 哈哈，哎，这年头，想要写点什么出来也是不容易啊。
20 年没有写过架空武侠小说了，前段时间一时兴起开始动笔。还以为写作能力退化了，没想到写得非常顺畅，于是拉来 AI 帮忙校对，分析，出主意，越写越嗨，一下子写了七八章。没想到几天后查了一下，竟然消耗了 4000 万 token ，花了 40 多美金。哎，嗨过头了，接下来就收敛了很多，不是每写一段就 run 一遍检查的 skill ，而是好好写完一章再一次性检查，需要 AI 查阅上下文的时候不允许 AI 调取正文部分，只准调取总结出来的内容的 summary （字数少很多），这样一下子减少了四五倍的使用量。 如果真要一直写下去，不知道还要花多少钱...我的程序员 partner 开玩笑说给我充个 500 块进去让我随便用。我说，你搞笑吧，你当 500 块是人民币啊，说充就充。 哈哈，哎，这年头，想要写点什么出来也是不容易啊。
20 年没有写过架空武侠小说了，前段时间一时兴起开始动笔。还以为写作能力退化了，没想到写得非常顺畅，于是拉来 AI 帮忙校对，分析，出主意，越写越嗨，一下子写了七八章。没想到几天后查了一下，竟然消耗了 4000 万 token ，花了 40 多美金。哎，嗨过头了，接下来就收敛了很多，不是每写一段就 run 一遍检查的 skill ，而是好好写完一章再一次性检查，需要 AI 查阅上下文的时候不允许 AI 调取正文部分，只准调取总结出来的内容的 summary （字数少很多），这样一下子减少了四五倍的使用量。 如果真要一直写下去，不知道还要花多少钱...我的程序员 partner 开玩笑说给我充个 500 块进去让我随便用。我说，你搞笑吧，你当 500 块是人民币啊，说充就充。 哈哈，哎，这年头，想要写点什么出来也是不容易啊。
Superalink 折扣要改了，有需要的提前囤一下（补充之前的攻略） 之前写过一篇大陆 5 日套餐的购买攻略： https://v2ex.com/t/1211147 前两天收到 Superalink 官方邮件，说 5 月 18 日起折扣结构要调整，和现在不一样了，简单说一下变化。 折扣变化 现在（ 5 月 18 日之前） 通过 affiliate 链接首次购买，直接减$5 。 5 月 18 日之后，改成阶梯制： 买 5 天及以上：减$2 买 7 天及以上：减$5 买 15 天及以上：减$7 ～$12 对于我们这种只买 5 日套餐的用法，优惠从$5 缩水到$2 ，涨价幅度不小。 我自己的做法 我按自己的用量估算了一下，提前买了 26 张 5 日大陆套餐的存量码，锁在旧折扣里，花了 142.74 元，够用大约 4 个月。 码买下来之后不用立刻激活，等要用的时候再激活就行，不会过期。（ 180 天期限） 如果你也在用 5 日套餐，觉得后续还会继续用，可以趁 18 号之前按需囤一些，买多少看自己，别为了囤而囤。 折扣码还是： ROY000000 链接： https://www.superalink.com/destination/aff/ROY000000 有问题可以回复，之前攻略帖里也有一些基础问题的说明。