Barret李靖

统计数据

80

文章

0

粉丝

0

获赞

22901

阅读

1天前

谁还不会做俩菜呢，但不是谁都能成为厨师。写代码这件事，门槛会越来越低，真正拉开差距的，会是架构、工程和管理能力。你得看得懂复杂设计，扛得住长期维护，带得动多人多AI协作，还能让系统在不断变化里继续稳定、生长、扩展。

#编程 #软件工程 #职业发展 #代码质量 #技术架构 #AI协作

5天前

把 OpenClaw 的记忆设计和 OpenSpec 的最佳实践用于 AI Coding，对于大需求和大重构先做文档编程，将方案、设计、影响面和执行流程等先沟通清楚，再执行。效果是：返工变得更少了。为了可以最大化沉淀和复用经验，本地采用 qdrant 对工作日志做向量索引，模型执行过程不仅不会忘记自己要干啥，还能根据当前做的事情，把最近一个月踩坑的过程翻出来看看。文档编程的另一个好处是，可以充分把 Github Copilot 按 Request 计费的策略给用起来，跑一晚上代码，才消耗不到 3% 的额度，😄

1周前

让 AI 好好干活儿，把事情做好，一句话扔给它显然是不够的。一句话来，一句话去，会让 AI 陷入到细节。陪伴式地结对编程，对人的消耗也特别大。最高效的方式是，将任务分成两个阶段，第一阶段打磨框架，第二阶段做精细化调优。前者需要人类想清楚事情的目标，以及产品服务的供给方式，给 AI 做好任务规划，让它可以大把大把吃 token；后者需要对 AI 执行结果做编排和重构，更多是为了对齐人类目标和 AI 理解之间的偏差。因此，对 AI 的管理，需要两块能力，一是需求管理能力，包含了对需求的分门别类、需求的拆解和细化、需求的优先级打标管理等，这是传统 PM/TL/PD 常干的事儿；二是让 AI 并行工作的能力，这会涉及到 AI 之间的合作与协同，AI 之间需要分派指令、执行任务、回馈结果，也需要经常性地解决冲突。当每个人都配备多个 AI Agent 的时候，如何管理 AI 会是一门新的学问，德鲁克老爷子提出的很多思想，在 AI 时代又需要进化啦😄

#AI #任务分配 #编程 #人机交互 #框架设计

1周前

当下的 OpenClaw🦞 使用体验，其实还挺像当年 ChatGPT 4.x 刚出来时的阶段。能用，也确实能解决不少问题，但总感觉离人类自己上手的效果还差那么一点点。ChatGPT 4.x 很多时候需要通过各种 Prompt 调优，极力去压榨模型的智力。 OpenClaw 的具体表现就是，对 token 的消耗特别大。原因也很简单，它需要在一个模糊且复杂的问题集上找到算法路径。整个过程是一种探索式计算，需要不断试探、回溯和修正，对计算量和上下文都会有很大的消耗。在当下这个阶段，想提升 OpenClaw 的“智商”，比较有效的办法，就是让它学习人类已经 SOP 化的一些操作。把人类已经验证过的路径直接变成能力模块，让 Agent 少走弯路。例如使用浏览器，可以用 agent-browser 这一类组件。它的原理是把浏览器协议能力暴露成可编程接口，让模型可以直接读取 DOM、操作页面元素、执行脚本，用结构化的方式去控制浏览器，从而绕开很多低效的探索。再比如对操作系统的使用，可以用 Hammerspoon。它通过 Lua 脚本桥接 macOS 的系统 API，让自动化脚本可以直接控制窗口、快捷键、菜单栏和应用状态。很多原本需要视觉识别、反复尝试的动作，会变成一次确定性的系统调用。对于不懂技术底层的人来说，安装 find-skills 会很大程度提升提升 OpenClaw🦞 的水平，因为它具备寻找人类 SOP 的技能。那 OpenClaw 的下一个“ChatGPT 5.x 时刻”什么时候会到来？我的判断是不会太远。当前大量的 OpenClaw 使用数据，在 computers/tools/browsers use 等场景里已经积累了非常多的数据集。大模型会根据真实用户的使用路径，加速自己的 RL 训练。 DeepSeek 已经证明了一件事情，推理能力是可以通过训练被内化到模型里的。接下来会发生的事情，是工具使用能力也会被逐渐内化。未来的模型会逐渐形成自己的工具世界模型，多轮工具调用、最佳调用路径、失败恢复策略等等，都会内化为模型能力。到了那个阶段，OpenClaw 的体验很可能会出现一次明显跃迁。今天很多人还在用 Claude Code 这样的工具，通过 Prompt、脚本和各种技巧去驱动 Agent 工作。整个过程有点像在 ChatGPT 4.x 阶段做工程，每一步都很依赖经验。在当下阶段，我也更愿意采用这种务实的使用方式：Claude Code + 打造“最锋利的剑”。所谓最锋利的剑，其实就是把工具使用的最佳实践不断聚合和沉淀下来。把浏览器操作、系统自动化、代码生成、文件处理这些能力逐渐模块化，变成稳定可复用的能力层，让 Agentic 工作真正跑起来。

1周前

朋友问我，有没有一种感觉：越用 AI 工具，越觉得作为程序员，自己要被替代。老实说，这种感觉或多或少是存在的。在过去，编程是一种很稀缺的技能。通常资历越老的程序员，能够解决的问题会越复杂，解决问题的速度也越快。但是今天，AI Coding 让程序员之间变得更加平权，大家都可以解决复杂问题，只要舍得花钱，速度也会非常快。那程序员是不是接下来要迎接一波下岗潮？我的判断是，这是必然的。对于那些没办法使用 AI Coding 来提升效能的程序员，肯定是要被淘汰的。但换个视角来看，对企业来说，企业的目标是交付价值。无论是古法编程的程序员，还是 AI Coding 的程序员，都是生产资料，在生产关系中是不可或缺的元素。程序员不会被全部干掉，他们一定会以一种更强、性价比更高的形式继续存在。 “程序员”的画像和技能结构会发生变化，岗位也会被重新定义。

1周前

AI Coding 极大提升了传统软件开发者的幸福度。以前很多想法，其实在脑子里早就把整个项目的编码工作做完了。现实世界再来一遍，从设计到实现、到调优、再到发布，基本都是体力活。现在的软件构建，更像是一种创作和表达的过程。跟 AI 讲清楚要做什么，要做到什么程度，必要的时候再讨论一下怎么做（很多时候这一步都不需要聊得太细）。剩下的时间基本就是看电影、听歌，或者写别的材料。幸福感确实提升了。不过幸福感提升，并不意味着工作量减少。脑子里的想法越来越多，AI Coding 的时间也越来越长。虽然很多事情可以远程指挥，但整体感觉还是一种陪伴式编程。人需要一直在旁边盯着，不是安慰它，就是鞭策它。为了让它稳定持续地干活，我自己的睡眠时间反而被压缩得越来越少。现在每天大概只睡四五个小时。🥲

1周前

为了让交付更快、更稳，我通常会先和 AI 一起把需求的整体设计讨论清楚，包括前端交互设计、后端 MVC 结构、代码逻辑抽象、组件复用、开放模块设计、稳定性设计，以及架构和工程层面的优化。一轮讨论结束之后，AI 通常会生成 3～5 个文件，对应不同维度的项目变更设计文档。接下来，就会让 AI 根据项目复杂度选择合适的模型配置，同时开启多个进程跑 CLI，或者拉起多个子 Agent 一起干活。这个模式的效率确实很高，不过带来的最大问题只有一个：钱不够烧。我在 Codex 上买了两个账号轮着用，Github Copilot 也买了两个账号。用了一段时间之后发现，Codex 的 token 限额算是最亲民的，5 小时窗口 + 周限额窗口。周限额有时候看起来还挺随机，昨天还显示要等一周才能恢复，结果第二天一看，额度已经恢复到 100%。 Github Copilot 刚开始没有太注意，它其实是按照 Request 来限流的。有一次为了调一个细节，一晚上来回聊了很多次，直接把月额度干没了。后来慢慢摸索出一个用法：专门让 Copilot 处理大的需求，一个 Request 里塞进去好几个复杂任务，反而会觉得“真香”。 Google One 的 Family 方案其实也很香，用 Antigravity Tools 做反代就能跑。不过最近封号有点猛，现在基本不太敢用了。当所有账号都被干到限流之后，也试过用国内的一些模型，比如 Kimi-k2.5、GLM-5。做一些常规的小需求其实问题不大，一旦遇到复杂问题，就很容易陷入无限递归循环：排查 → 修复 → 没改好 → 继续排查。这个时候就会特别怀念 Codex-5.3-xhigh 和 Claude-Opus-4.6。另外，这几天刚出来的 Codex 5.4 表现更明显，之前需要排查好几轮才能解决的问题，它经常一把就能过。

1周前

一家公司或者一个团队，其智能的密度，可以用两个指标来度量。一个是 token 消耗的量级，另一个是人和 AI 做事的占比。智能密度越高，并不一定意味着事情会做得更好，有时候反而会更混乱。智能密度的背后，还需要有秩序的密度，也就是更标准化、更规范化的生产方式。所以团队真正需要关注的，其实是两件事：一是人的经验如何持续传递给 AI。二是 AI 之间如何相互学习，让能力不断累积。 Skills 可以理解为对人大脑经验的一次蒸馏。让 AI 进入最佳干活状态，本质就是让它学会人的 skills，逐渐走向 SOP 化的生产模式。当 skills 被不断沉淀之后，一件有意思的事情就会发生： AI 与 AI 之间可以通过这些 skills 互相学习，每个人的数字分身也可以通过这些经验不断强化自己的能力。最近看到 EvoMap GEP 这个协议，它试图把经验本身做成一种可流通的能力资产，让经验可以被记录、传播和复用。如果这个方向成立，未来团队里的知识流动方式可能会发生变化。经验不再只是沉淀在文档里，而会以 skills 的形式，在人和 AI 之间持续流动。

1周前

vibe coding 的项目一旦变得庞大，每次让 AI 写代码之前，都需要先让它把 PRD 和系统设计写清楚。先做文档编程，再做代码编程。如果你稍微停下来观察一下，会发现一个很有意思的现象：有些 AI 一旦开始写代码，就会沉浸在自己的逻辑实现里，几乎完全不顾项目原有的设计。即便你已经提出明确要求，它仍然会受限于上下文窗口和信息宽度，对整个项目缺乏完整理解。这会带来很多维护性问题。它不会复用已经实现的业务组件，设计数据库时会产生各种冗余，还会不断衍生新的实体和概念，让系统结构越来越复杂。代码可以交给 AI 去写。产品设计和架构设计，仍然需要人来把关。每次让 AI 做大型重构或者功能改造之前，我都会先让它把需求分门别类，做好抽象和解耦。即便如此，只要有一些地方考虑不周，AI 依然会生成大量难以维护的代码，性能逐渐下降，项目变更的复杂度也会迅速上升。🥲

#AI编程 #文档编程 #系统设计 #项目管理 #代码实现 #逻辑沉浸 #信息上下文 #维护性问题

2周前

在模糊地带或者新领域探索的时候，拿到结果会是一件比较有挑战的事情，因为没有做过，甚至没有先例可循。如果这件事情过去有人做过，并且效果还不错，那就把他们的经验拿过来，重复执行，放大执行。如果没有做过，也不用浪费太多时间去纠结和争论，先行动起来，不断尝试，在尝试中找到行之有效的办法，再重复和放大。查理芒格也说过，一辈子做对两件事就可以很富有：寻找什么是有效的，重复它；发现什么是无效的，避免它。非常对味😄

1个月前

在跟大模型对话的过程中，缓存经常是一个被忽略的对象，尤其是在大文档、多轮对话和长时间连续追问这些重上下文场景下。以 Claude 的 5min prompt cache 为例，从缓存中读取 token 的价格只有不缓存的十分之一。假设你在针对一本 10 万字左右的书籍做问答，围绕同一份内容连续交互 50 轮：不使用缓存时，每一轮都要把这 10 万字完整送进模型，总成本是 50 × S；使用缓存时，只在第一次写入付出 1.25 × S，后续 49 次读取只需 0.1 × S，总成本约为 6.15 × S。换算下来，整体成本节约约 87.7%。与此同时，每一轮响应时间也会明显变快，因为不需要反复携带、解析和对齐那一大坨背景内容，模型可以更快进入真正回答问题的阶段。 ChatGPT 和 Gemini 也做了类似的工作，只不过它们是在平台侧隐式处理的，Gemini 甚至还会因为请求命中 cache 而给用户退费😄 缓存除了省钱，也改变了模型“看待上下文”的方式。没有缓存时，这些背景只是每一轮对话里的一段 prompt 文本，模型每次都会重新读一遍、重新权衡一遍，时间一长就容易出现理解松动和判断漂移。而一旦进入缓存，这些内容就不再是普通输入了，它会变成推理开始前的前置状态，等于帮模型把世界观给固定了下来。从机制上看，这正是 attention reuse。大模型在推理时，当前 token 会与既有上下文的 key-value 做注意力计算，缓存做的事情，是把稳定、不需要反复建模的上下文 KV 固化并复用。后续每一轮推理，都直接在这套已经对齐好的注意力状态之上展开，attention 不再浪费在“重新理解背景”，而是更集中地用于当前问题。

1个月前

Node.js 进程被 native code 偶发性杀死，stderr log 除了 sigabort 外毫无端倪，用最原始的请求对账方式查了一晚上，终于在三台机器上找到了相同规律，最后发现是 schedule 任务里 rocketmq 的 c++ addon 存在 use-after-free 问题。又涨了几个痛苦经验：1）请求对账不能只看 nginx日志，定时任务也要看；2）不能只看进程挂掉前 2s 的日志，至少往回拨 20s；3）那些单测不够多社区使用量不够大的 c++ 包千万不要往业务仓库里引。感觉这事儿，应该让 AI 去查，明天试试把权限开给 AI，看看能不能走通 AI Ops，🥹

2个月前

朋友问我，如何让自己更有生命力，我想了几点： 1. 让自己兴奋起来，如果写代码会让自己兴奋，那就写代码；如果做架构能让自己兴奋，那就做架构；如果做应用能让自己兴奋，那就做应用。我们都需要找到正向循环，从而变得积极主动。 2. 定一个难一点的目标，追一追，追不到也没关系，先找到属于自己的心流，让自己沉浸其中。 3. 打开自己，拥抱这个世界，绷紧的弦一旦有了松动，再弹奏几曲，就彻底放开了。

2个月前

很多问题是没有标准答案的，关键不在想出答案，而是做出决策，然后根据决策的结果动态推进事情的变化。

3个月前

Google 检索 banana slides 的时候，看到 Manus 排到了首位，不得不说，在拾取自然流量这方面，Manus 很下功夫的，👍 也很好奇下面 4.8 评分以及一百多万的评分参与量是如何产生的，看了下网页源码，才发现，这又是一个巧妙的 SEO 思路。 Google Web Spider 定义了大量结构化的网页 Scheme 描述能力（图三），这些 Scheme 会直接影响你的网页在搜索结果中的呈现方式，例如在搜索结果页，它可以直接透出网站的搜索框、热门网页列表、推荐入口、用户评分、特色卡片等。随便瞎写肯定不行，Google 会进行交叉验证，对于评分很高/值得信任的网站，它会考虑将网页里描述的信息直接呈现出来，对用户来说，这种信任加权的体验是相当奏效的。所以，如果你的某几个功能在搜索引擎里头很受欢迎，不妨在网页元数据的标注上，再下点功夫，这会给搜索引擎带来更大的亲和力。

4个月前

入魔了😅，跟眼镜聊了半个小时。

#入魔 #眼镜 #聊天 #半个小时 #无奈

4个月前

智能系统正在迅速吸收人类的知识和能力。那些曾经被视为技能的东西，也逐渐被算法内化为基础功能。从 fine-tuning 到 RL，现在它可以做到理解语言、执行指令、完成一些复杂的任务，甚至主动学习新的模式来创造工具。有没有发现？这变得和人类有些类似了。也正因如此，智能的边界开始变得清晰。AI 更擅长重现确定性的世界，却没法自发地提出问题。它可以在规则内进行优化，但不具备打破规则的动机。所以人的价值正在被重新定义。执行性的工作会逐渐转向机器和智能，而探索成为新的分工，人类的优势不再是熟练度，而是方向感和创造冲动。当机器学习世界的规律，人类必须学习如何拓展世界的边界。

#智能系统 #AI #机器学习 #人类价值 #探索

4个月前

工作的幸福感来自于对方向的选择，以及对环境的选择。知道自己想做什么、为什么要做、怎么做才对，就不会盲目追求绩效。把每一个任务放进自己的“人生系统”去规划和判断，会获得更长期和更有效的 ROI，这是对方向感的把握，让自己远离“瞎忙”的幻觉。遇到让自己不舒服或者限制生产力的人或事，坚决远离！坚定 Say no！如果同事让你低效，那就少接触。如果上司让你窒息，那就换个部门。如果整个组织都让你无法发挥，那就换个生态。这不是逃避，而是主动优化自己的生存环境。高效能不是靠隐忍堆出来的，而是靠选择筛选，真正的成熟，是明白“环境比努力更重要”。

#工作幸福感 #方向选择 #远离负面环境 #人生规划 #环境重要性

4个月前

OpenAI 有一个 privacy 二级域名，专门用来处理数据隐私问题，你可以要求 OpenAI 导出以及删除你的所有数据，也可以声明不允许你的数据参与大模型的训练。我尝试将过去两年跟 ChatGPT 的对话数据导了出来，结果令人震惊：总共 220Mb+ 的内容，其中纯文本就有 45Mb，约两千万字，还包含大量音视频和图片文件。如果把这些内容重新结构化拼凑起来，几乎可以复原出一个完整的“数字分身”——它记录了我的思考、表达、偏好、甚至情绪节奏。这是一件令人感到愉悦的事情，不过也是个恐怖故事，意味着跟大模型保持长期交互之后，基本就是“赤裸裸”地暴露在它们面前了。在 AI 时代，我们既在创造自己的“Second Me”，也在不断把真实的自我交托给算法。

#OpenAI隐私 #ChatGPT数据导出 #数字分身 #AI数据暴露 #个人数据隐私

5个月前

为了测试 OpenAI Agent SDK，早上给 OpenAI 的 API 账户充了点钱，结果本地跑 Demo 的时候代理没配好，可能是因为换了个不常用的 IP，被 OpenAI 识别为异常请求，直接把我的账户给封了…… 跟 ChatGPT 聊了一年多，它对我的“理解”逐渐加深，回答问题也适配了我的风格，而且还会跟我的历史提问做关联，感觉就像在跟一个老朋友聊天一样。临时换了个账号，尝试聊了几个话题，感觉味道不太对。这么一封，还真有点不习惯。所以，有啥方案可以做好 Memory 的管理，让记忆在跨账号、跨平台情况下，仍可以继续传承下去？（另外，我这个账号还有机会申诉回来不？🤣）

#OpenAI账号被封 #Agent SDK测试 #Memory管理方案 #ChatGPT使用体验 #账号申诉

5个月前

AI 编程不是让你变懒，而是让你更像一个系统设计者。Coding 的确变少了，但你在 Architecture & Orchestration（架构与编排）上，做得比过去任何时候都多。没有对代码的组织和结构化做设计，全靠 Vibe coding，项目是很难长大的。功能越多，越容易在后期陷入稳定性差、鲁棒性低、可维护性崩塌的泥潭。 AI 本身并不关心这些系统属性，这也意味着，如果人类不主动构建它的秩序，那 AI 产出的代码就只能是一次次补丁的堆砌。

#AI编程：自学or科班？新旧码农之争· 156 条信息

#AI 编程 #系统设计 #架构与编排 #代码质量 #秩序构建

5个月前

指挥 Codex CLI 干了四五个小时，把之前写的“网页音视频加速播放”油猴脚本改成了 Chrome 插件，已经提交商店审核。快速记录几点感受： 1. 聊四到五个小时，开始限制 token 了，不太够用，聊的过程中，感觉 token 消耗是个黑盒，不知道它在干什么 2. 当遇到报错时，会给它提供报错信息以及截图，但一开始总是有点不信任它能把问题搞定 3. 代码一旦改坏了，最想做的就是回到上一步，但上一步我给它安排了四五个任务，这时候要是只让它移除其中某段代码，又怕引出新的报错。事实证明，最稳妥的方式还是每个 feature 都独立进入 git 管理，否则回退会非常麻烦。feature 都进入 git 管理 4. codex 读代码读的实在是太认真了，以至于执行任务的速度特别慢，对于稍微复杂点的任务，或者同时布置了多个任务，需要 5～20min 才能搞定 5. 每次对话结束，我都希望它能自动把过程记录下来，但它做得并不好，总结的内容也很一般。 6. 80% 情况写出来的代码能直接跑；出错的那 20%，经过第二轮调教后大多也能跑通。 7. 看着它执行某个任务的空档，脑子里有了新的想法，会想让它并发执行很多任务，但又担心它处理不过来。 8. 95% 都是 AI 写代码，但有些问题它排查得实在是太慢了，会忍不住自己上手，比它要快很多。 9. 有部分任务它处理的并不好，例如让它生成 svg 图标，效果很差。 10. 表达清晰很重要，如果任务描述的过于抽象，它可能会理解错，如果跟他沟通的时候，具体到函数名或 DOM id，它的处理基本会更准确。以上遇到的问题，基本都找到了好的解法，等后面整理了再分享。还是要多用，才能不断优化工具的使用。总的来说，整个项目完成的速度已经是我自己的 5 倍以上，因为省略了学习陌生知识的时间。说实话，一个月花 2～3k 在 AI Coding 上，完全是值得的，相当于给自己找了个外包。

#AI Coding #Codex CLI #Chrome 插件 #效率提升 #外包

5个月前

“AI 味”这件事，本质上是语言模型逃不掉的命运。因为它从诞生的第一刻起，就不是在“表达自己”，而是在“复刻统计平均”。模型的训练目标只是预测下一个词最可能是什么，它不会思考“我为什么要说这句话”，也没有任何主观意图。于是，它的语言天然带着一种“概率最优解”的味道——对，但平，准，但无魂。更致命的是，后期的 RLHF 奖励机制会进一步放大这种味道。人类标注者倾向于给那些“中庸、安全、全面”的答案高分，于是模型被训练成了“八面玲珑”的选手：不表态、不激进、不出格。你经常看到的那些“既有优势，也有挑战”“具有重要意义”“未来前景广阔”这样的句式，就是这种中庸激励下的自然产物。这也解释了为什么 AI 写出来的东西，即便形式上模仿得再像，读起来仍像是“没有血肉”的文字。它没有世界模型，没有时间感，也没有“我非说不可”的冲动，它生成的只是“统计上最合理”的答案，而非“我真心想说”的表达。这种根源性的差异，就像是合成香料和炖煮骨汤的差别——味道可能接近，但总有一股“假”的底色。所以，AI 味并不是一个可以靠技巧完全去除的瑕疵，而是统计学习范式的体味。你可以靠风格微调、个性化训练和精心设计的提示词让它淡一点，但只要它的底层逻辑还是“预测最可能的词”，这种味道就永远不会彻底消失。换句话说，它可以越来越像人，但永远不知道“成为人”是什么感觉。

OpenAI GPT-5发布引发用户不满，阿尔特曼回应质疑· 158 条信息

#AI #语言模型 #中庸 #无情感 #统计学习

5个月前

一篇论文要上顶刊、顶会，需要经历三个阶段： 1）首先是产出 preprint 初稿，初稿完成后发布到 arXiv 或 openReview 等平台，主动获得快速曝光，以吸引潜在的审稿人注意； 2）紧接着是向对应的期刊或会议投稿，会经历初审、正式审核、问题澄清等过程，顶会的拒稿率在 80% 左右； 3）最后完成修订和补充后才会被正式收录，整个流程通常持续半年甚至一年以上。顶刊顶会只占论文总量的不到 10%，却贡献了超过 50% 的引用量；剩下的 90% 虽然很多是增量性研究或局部实验，没有里程碑式的突破，但也为后续研究提供了大量数据、方法和对比基线，价值同样不可忽视。那“论文”到底是什么？从顶会顶刊的分类来看，它本质上是人类知识的一种系统化表达形式。以计算机科学为例，NeurIPS 偏重机器学习和人工智能基础理论，CVPR 聚焦计算机视觉，ICML 和 ICLR 涵盖模型架构、训练方法、优化算法等方向，SIGGRAPH 专注图形学与交互，而 Nature、Science 等综合性期刊则跨越学科边界，关注具有颠覆性意义的研究成果。可以说，论文汇聚了人类在算法、模型、系统、工具、应用等不同维度上的思考与探索。我比较推荐开发者去多关注一些前沿、偏工程性的 Agent 论文，它们里面往往埋藏着大量新颖的思路和独到的启发，这些思路本质上就是为了解决工业界里那些“又难又深”的问题而提出的。

#顶刊顶会 #论文发表 #科研价值 #知识系统化 #前沿技术

5个月前

对携程的投诉告一段落，明天要去搬砖没空折腾了，携程给的答复是——退还所有费用，并继续赔偿两百元现金（有强调是赔偿不是补偿）。赔偿的理由是，平台在处理过程中存在过失，给用户造成了不好的体验，因此赔偿；同时，恳请我能够删除帖子（也可以不删，全凭自愿）。首次投诉的时候，我询问了携程，它的上级监管部门是谁，携程客服说支持所有形式的监督，当然这里包括了社交媒体渠道，所以帖子我就不删了，继续监督，实事求是。对于费用问题，仍然是之前的观点，该我承担的部分不推诿，携程的赔偿覆盖了我要承担的费用，因此我无需额外再付费。我在取车时，车上就有较多划痕，其中有一道还比较明显（有录像），如果商家对车辆进行维修时，将其他有划痕的部分也做了修复，由此产生的保险附加费用，以及维修时长增加产生的停运费，不应该计算到我头上，继续监督😜

#携程投诉 #退还费用 #赔偿 #车辆划痕 #用户体验