<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>CSS森林(CSS Forest) - Thought</title>
		<description>一个页面仔的成长之路</description>
		<link>https://www.cssforest.org</link>
		<language>zh-cn</language>
		<copyright>cssforest.org</copyright>
		<author>
			<name>GhostZhang</name>
			<email>ghostzhang@cssforest.org</email>
		</author>
		<follow_challenge>
    		<feedId>62377656480471040</feedId>
    		<userId>61695717095510016</userId>
		</follow_challenge>
		<atom:link href="https://www.cssforest.org/feed/thought/index.xml" rel="self" type="application/rss+xml" />
		
		
			
				
				<item>
					<title>日抛型软件？</title>
					<author>Ghostzhang</author>  
					<description>&lt;p&gt;最近又出现了一个新概念，叫『日抛型软件』，大意是 AI Agent 的能力可以在需要时快速完成一些小工具的开发，完全不用像现在这样去搜索、下载、安装。&lt;/p&gt;

&lt;p&gt;『微信小程序』2017年刚出来时的口号也是『用完即走』，也有人觉得app的日子到头了，以后用户需要时只要打开微信里的小程序，分分钟搞定，再也不会去搞那些需要下载、安装、注册之类的app。实际呢？十年过去了，世界并没有按当初小龙预期的方向发展，小程序确实提供了一个不用下载app就可以使用服务的方式，但对app的影响并不多，该上线的app一个也没少。&lt;/p&gt;

&lt;p&gt;正如当下已经有人意识到，对于有明确目标，需要确定性结果的场景，使用脚本比使用大模型更靠谱一样。工具是解决问题的，对于那些有明确目标，需要确实性结果的场景，使用app要比使用 AI Agent 更高效。只是使用的方式会从人去操作变成 AI 去调用。&lt;/p&gt;
</description>
					<pubDate>2026-04-20 23:54:00</pubDate>
					<link>https://www.cssforest.org/thought/%E6%97%A5%E6%8A%9B%E5%9E%8B%E8%BD%AF%E4%BB%B6.html</link>
					<guid isPermaLink="true">https://www.cssforest.org/thought/%E6%97%A5%E6%8A%9B%E5%9E%8B%E8%BD%AF%E4%BB%B6.html</guid>
				</item>
			
		
			
				
				<item>
					<title>你的好运可能来自于别人的忍让</title>
					<author>Ghostzhang</author>  
					<description>&lt;p&gt;听过很多关于『路怒症』的话题，我也花了不少时间在调整心态上面，但是当前面车各种让人『心塞』的操作时，还是免不了要鄙视一番。&lt;/p&gt;

&lt;p&gt;前几天在路上看到两辆车停在路口，司机在边上等交警。突然间想到，我开了十年的车出过三次事故（二次被追尾、一次变道时后车从盲区突然间出现刮到了车门），可能并不是我开得多好，而是别人的忍让和包容。&lt;/p&gt;

&lt;p&gt;如果当我变道、插队、超车时后车不让我，那么结果会是怎样？当别人变道、插队、超车时我也不相让时，结果会是怎样？&lt;/p&gt;

&lt;p&gt;没有人喜欢被插队，但是在开车的场景里，插队这件事是很常见的，可能因为某些原因，你必须在到达下一个路口之前进行变道而插队。同样的别人也可能会因为某些原因想要插队。很显然这个过程是被插队的一方是需要忍让的，当然如果你车技不错的话，是可以试试不让…但总有一方需要做出让步，不然可能会导致大家都走不了。有时候感觉就是在比谁更『硬气』，谁更能坚持，但意义何在？&lt;/p&gt;

&lt;p&gt;每次成功的插队或超车都是他人的忍让，因此不要觉得自己占到了便宜。被插队或超车时，也要平常心视之，是你的大度才让大家都能顺畅的通行。&lt;/p&gt;
</description>
					<pubDate>2024-10-09 16:01:00</pubDate>
					<link>https://www.cssforest.org/thought/%E4%BD%A0%E7%9A%84%E5%A5%BD%E8%BF%90%E5%8F%AF%E8%83%BD%E6%9D%A5%E8%87%AA%E4%BA%8E%E5%88%AB%E4%BA%BA%E7%9A%84%E5%BF%8D%E8%AE%A9.html</link>
					<guid isPermaLink="true">https://www.cssforest.org/thought/%E4%BD%A0%E7%9A%84%E5%A5%BD%E8%BF%90%E5%8F%AF%E8%83%BD%E6%9D%A5%E8%87%AA%E4%BA%8E%E5%88%AB%E4%BA%BA%E7%9A%84%E5%BF%8D%E8%AE%A9.html</guid>
				</item>
			
		
			
				
				<item>
					<title>团队是『人找事』还是『事找人』</title>
					<author>Ghostzhang</author>  
					<description>&lt;p&gt;从团队的定义来看，是泛指为某种目的而组成的集体。也就是应该是大家为了某种共同的目的而走到一起。在当前的公司中，大多是因为公司想做某件事，然后把愿意做这件事的人聚集起来一起分工做事，这个阶段是共创的。但这事做完或中止之后呢？人还在事没了，当初聚到一起的『目标』不见了，这时就会逐渐变成『人找事』，每个人自己去想怎么适应公司的新目标，即所谓的『OKR』。&lt;/p&gt;

&lt;p&gt;《重新定义公司》中Google的团队运营模式确实很棒，也是『OKR』能真正落地的原因，团队始终是以共同的目标组成的。团队成员是因为共同的目标而聚集在一起，而不是先聚在一起再分摊一个目标。但国内的公司很难学习，总体还是那种对资源的『占有欲』在作祟。组织结构在某种程度上限制了成员的流动、考核的机制也制约了成员的选择，『OKR』变成换汤不换药的『KPI』。&lt;/p&gt;
</description>
					<pubDate>2024-08-20 18:36:00</pubDate>
					<link>https://www.cssforest.org/thought/%E5%9B%A2%E9%98%9F%E6%98%AF-%E4%BA%BA%E6%89%BE%E4%BA%8B-%E8%BF%98%E6%98%AF-%E4%BA%8B%E6%89%BE%E4%BA%BA.html</link>
					<guid isPermaLink="true">https://www.cssforest.org/thought/%E5%9B%A2%E9%98%9F%E6%98%AF-%E4%BA%BA%E6%89%BE%E4%BA%8B-%E8%BF%98%E6%98%AF-%E4%BA%8B%E6%89%BE%E4%BA%BA.html</guid>
				</item>
			
		
			
				
				<item>
					<title>『价值论』抑制了创新</title>
					<author>Ghostzhang</author>  
					<description>&lt;p&gt;最近很讨厌『价值』这个词，团队里人人在说『价值』、事事在说『价值』，但没人能说清楚『价值』是什么……&lt;/p&gt;

&lt;p&gt;当你想做一件事，想得到团队的支持时，你需要面临的第一个问题就是『这件事有什么价值？』，然后你可能就会因为『找不到价值』而放弃。这跟领导常说的『先干了再说』是很矛盾的。让人无所适从。&lt;/p&gt;

&lt;p&gt;『有什么价值？』这个问题让很多想法被抛弃了。也许很多想法确实不会带来什么收益，但正如《你的灯亮着吗？发现问题的真正所在》中说的&lt;/p&gt;

&lt;blockquote&gt;
  &lt;p&gt;别去费力帮缺乏幽默感的人解决问题。
有时一些看起来很滑稽的想法中，藏着解决问题的方案。&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;正是这些看起来没什么价值的想法，才是创新的温床。我无法让每个想法都有价值，但有价值的方案是在这所有的想法中产生的。&lt;/p&gt;

&lt;p&gt;也许正是因为不愿意承担『创新的成本』，才只能跟在别人后面捡漏，等着别人滩出一条路，然后去『借鉴』。&lt;/p&gt;
</description>
					<pubDate>2023-12-28 11:56:00</pubDate>
					<link>https://www.cssforest.org/thought/%E4%BB%B7%E5%80%BC%E8%AE%BA-%E6%8A%91%E5%88%B6%E4%BA%86%E5%88%9B%E6%96%B0.html</link>
					<guid isPermaLink="true">https://www.cssforest.org/thought/%E4%BB%B7%E5%80%BC%E8%AE%BA-%E6%8A%91%E5%88%B6%E4%BA%86%E5%88%9B%E6%96%B0.html</guid>
				</item>
			
		
			
				
				<item>
					<title>方法与方法论</title>
					<author>Ghostzhang</author>  
					<description>&lt;p&gt;解决一个问题的叫方法，解决一类问题的叫方法论。但方法论并不一定就会比方法更『优雅』，因为抽象层次更高，而『大道至简』，越简单的方法适用性越广。&lt;/p&gt;

&lt;p&gt;一直对一个例子印象很深，『假设有一根针掉到了地上，你要如何找到这根针？』最先能想到的方式就是用吸铁石在地上找，但是怎么找呢？可能有同学会说从角落里一点点找起，没错，可以的。如果现在来了几个朋友一起帮忙找，又可以如何做呢？每个人分一个角落？如果还多人呢？可能你会发现，有些地方可能会被多个人重复找，有些地方又可能会漏掉。所以，用吸铁石找只是一个方法。&lt;/p&gt;

&lt;p&gt;可以在地上画出一个个的方格，然后每个人分配一个区域各自进行搜索，相比用吸铁石的方法，这个方法可以解决多人合作、重复、遗漏等问题，而且不仅可以解决针的问题，所以找东西的问题都可以用这个方法来解决。这个画方格的方法就是一个可以解决一类问题的方法论。&lt;/p&gt;

&lt;p&gt;但是看起来这个方法论并没有很优雅，甚至有些笨拙。这说明更高抽象层次的方法论并不一定就更优雅，如果你想从方法找到方法论，那可能得往上找，而不是往下找。&lt;/p&gt;
</description>
					<pubDate>2023-03-17 18:53:00</pubDate>
					<link>https://www.cssforest.org/thought/%E6%96%B9%E6%B3%95%E4%B8%8E%E6%96%B9%E6%B3%95%E8%AE%BA.html</link>
					<guid isPermaLink="true">https://www.cssforest.org/thought/%E6%96%B9%E6%B3%95%E4%B8%8E%E6%96%B9%E6%B3%95%E8%AE%BA.html</guid>
				</item>
			
		
			
				
				<item>
					<title>关于ROI</title>
					<author>Ghostzhang</author>  
					<description>&lt;p&gt;如果你相信二八定律，那你应该知道，用20%的投入就能取得80%的信息，但这些信息只有20%的价值。专业的人往往是花80%的精力去研究那20%的信息。因此不要觉得别人花大力气研究的小知识ROI不够，是在浪费时间，这是商人思维，不是专家思维。&lt;/p&gt;
</description>
					<pubDate>2023-02-09 20:33:00</pubDate>
					<link>https://www.cssforest.org/thought/%E5%85%B3%E4%BA%8EROI.html</link>
					<guid isPermaLink="true">https://www.cssforest.org/thought/%E5%85%B3%E4%BA%8EROI.html</guid>
				</item>
			
		
			
				
				<item>
					<title>关于尊重</title>
					<author>Ghostzhang</author>  
					<description>&lt;p&gt;尊重别人，第一是尊重差异，第二是尊重别人的劳动。简单地说就是不要把别人的付出看成是很简单的事情。也许你很容易就做到的事，对别人来说十分的困难。&lt;/p&gt;
</description>
					<pubDate>2023-02-09 20:06:00</pubDate>
					<link>https://www.cssforest.org/thought/%E5%85%B3%E4%BA%8E%E5%B0%8A%E9%87%8D.html</link>
					<guid isPermaLink="true">https://www.cssforest.org/thought/%E5%85%B3%E4%BA%8E%E5%B0%8A%E9%87%8D.html</guid>
				</item>
			
		
			
				
				<item>
					<title>关于产品目标和用户目标</title>
					<author>Ghostzhang</author>  
					<description>&lt;p&gt;产品目的有两个：一是卖出去（更多人用/生存），一是赚到钱（实现盈利/发展）。我们平常所说的所谓产品目标，是说如何实现这两个目的的策略方案。更多的是产品的运营方案，卖不出去的产品功能做得再好也没用。&lt;/p&gt;

&lt;p&gt;用户目标也是类似的，用户不会说想用你的产品怎样怎样，而是我有个问题或困难，有什么产品能帮到我，对于这个功能/服务我愿意付出多大的成本（时间/金钱）。这里多说一句，用户付出的成本并不一定是自愿的，有些时候可能是不自觉的，比如玩游戏、刷短视频、直播购物。&lt;/p&gt;

&lt;p&gt;所以我们说的『用户目标』其实是产品如何更好地帮到用户解决问题。本质其实是产品如何设计的问题。&lt;/p&gt;

&lt;p&gt;很显然，以不同的产品目的作为产品设计的指导，得到的方案会有很大的不同。实际场景中，产品往往只关注自己的目标，而忽略用户的目标。但因为产品想要卖出来甚至赚到钱，就必须取得用户的喜爱，真实的解决用户的某些问题，所以也就又回到了满足用户需求的维度上来。不过这种产品跟那些真正以用户目标为指导的产品还是能感受到差异的。最大的体现就是只要一不小心，就想从用户身上搞钱。&lt;/p&gt;
</description>
					<pubDate>2023-02-03 18:36:00</pubDate>
					<link>https://www.cssforest.org/thought/%E5%85%B3%E4%BA%8E%E4%BA%A7%E5%93%81%E7%9B%AE%E6%A0%87%E5%92%8C%E7%94%A8%E6%88%B7%E7%9B%AE%E6%A0%87.html</link>
					<guid isPermaLink="true">https://www.cssforest.org/thought/%E5%85%B3%E4%BA%8E%E4%BA%A7%E5%93%81%E7%9B%AE%E6%A0%87%E5%92%8C%E7%94%A8%E6%88%B7%E7%9B%AE%E6%A0%87.html</guid>
				</item>
			
		
			
				
				<item>
					<title>沟通中容易引起冲突的表达</title>
					<author>Ghostzhang</author>  
					<description>&lt;p&gt;除了『训斥』，沟通中容易引爆情绪、引起冲突的表达，还有这几种句式。&lt;/p&gt;

&lt;p&gt;第一种是『责备』，指责对方。如『你不早说』、『这都不懂』。听起来就很无理取闹。&lt;/p&gt;

&lt;p&gt;第二种是『反问句』，将显而易见的事情用反问句说出来，自带嘲讽buff。如『这么简单的问题你不知道吗？』、『你不会拿过来吗？』。而且这种句式会给人带来一种上位者的感觉，容易让人上瘾，不注意的话会变成习惯。而对于听的人来说，是很不好的一种体验。『明知故问』跟骂人家『蠢』并不差别。&lt;/p&gt;
</description>
					<pubDate>2021-09-08 14:50:00</pubDate>
					<link>https://www.cssforest.org/thought/%E6%B2%9F%E9%80%9A%E4%B8%AD%E5%AE%B9%E6%98%93%E5%BC%95%E8%B5%B7%E5%86%B2%E7%AA%81%E7%9A%84%E8%A1%A8%E8%BE%BE.html</link>
					<guid isPermaLink="true">https://www.cssforest.org/thought/%E6%B2%9F%E9%80%9A%E4%B8%AD%E5%AE%B9%E6%98%93%E5%BC%95%E8%B5%B7%E5%86%B2%E7%AA%81%E7%9A%84%E8%A1%A8%E8%BE%BE.html</guid>
				</item>
			
		
			
				
				<item>
					<title>关于『训斥』这种表达方式</title>
					<author>Ghostzhang</author>  
					<description>&lt;p&gt;前些天遇到一个事，小朋友对于家长训斥自己没礼貌（对家长态度不好）这件事不开心，找我唠叨。当时我表面虽然没表现什么，但第一时间心里在想，尊敬长辈不是应该的吗？对长辈态度不好本身就不对，说你两句怎么啦？但想想再教训她一次没什么意思，还可能让她更伤心，最终只是听她说完。之后就在想，总得把道理讲通吧，尊敬长辈是个好品质，还是得让她学会。『训斥』做为一种表达方式，到底应该如何调整才有效传达训斥内容的目的呢？&lt;/p&gt;

&lt;blockquote&gt;
  &lt;p&gt;训斥 xùnchì
严厉的或正式的谴责，尖锐的申斥
训诫与斥责。&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;一般是在晚辈做了什么不好的事情之后，长辈对于晚辈的一种教育手段，其目的其实是希望晚辈能长记性，认识到自己做错了，以后要留心改正，真正想表达的是一种担心、关心。但由于往往伴随着『大音量』和『生气』等容易让冲突升级的方式，所达到的效果大多是不欢而散。不但晚辈听不进去，还可能变本加厉，进一步破坏双方的关系。&lt;/p&gt;

&lt;p&gt;没有人愿意被别人训斥，即使明知自己做错了，这是本性。被训斥往往意味着不被认可，对于人这种社会性动物来说，是从骨子里不想要的。那为什么家长还是喜欢用这种方式教育孩子呢？我想大多数时候是因为『无法讲道理』，年纪太小没有达到可以讲道理的条件基础，再加上大多数时候事情发生时也没有太多的时间慢慢讲道理，那样『印象不深，以后还会犯』，先得让孩子认识到事情的严重性再说。当然本质上还是因为地位的不平等，小朋友处于弱势地位，所以大人可以用暴力的方式处理问题。&lt;/p&gt;

&lt;p&gt;尊重长辈，最重要的是对家里长辈要尊重。在家里就算不规矩了，长辈还是会包容，那是自家人，因为包容所以更应该被尊重，而不是因为包容反而更肆无忌惮不尊重长辈。可惜这个道理别说小朋友了，大多数人都是不懂的，只会觉得理所当然。&lt;/p&gt;
</description>
					<pubDate>2021-09-08 14:31:00</pubDate>
					<link>https://www.cssforest.org/thought/%E5%85%B3%E4%BA%8E-%E8%AE%AD%E6%96%A5-%E8%BF%99%E7%A7%8D%E8%A1%A8%E8%BE%BE%E6%96%B9%E5%BC%8F.html</link>
					<guid isPermaLink="true">https://www.cssforest.org/thought/%E5%85%B3%E4%BA%8E-%E8%AE%AD%E6%96%A5-%E8%BF%99%E7%A7%8D%E8%A1%A8%E8%BE%BE%E6%96%B9%E5%BC%8F.html</guid>
				</item>
			
		
			
				
				<item>
					<title>关于一致性</title>
					<author>Ghostzhang</author>  
					<description>&lt;p&gt;界面统一，结构稳定的作用之一，是为老用户提供炫耀的资本。怎么理解呢？老用户可以通过传授经验给新用户，从而获得成就感，从各类软件教程就可以看出，这也是软件自我传播的一种途径。如果这个产品经常做大的改版，老用户这种成就感就很难获得，同时还会打击用户使用这个产品的热情，因为可能下一次更新，就看不到熟悉界面了，没有亲切感，甚至会因此质疑产品的可靠性，谁知道哪天突然就不能用了呢？！完全有可能！&lt;/p&gt;
</description>
					<pubDate>2020-09-29 17:48:00</pubDate>
					<link>https://www.cssforest.org/thought/%E5%85%B3%E4%BA%8E%E4%B8%80%E8%87%B4%E6%80%A7.html</link>
					<guid isPermaLink="true">https://www.cssforest.org/thought/%E5%85%B3%E4%BA%8E%E4%B8%80%E8%87%B4%E6%80%A7.html</guid>
				</item>
			
		
	</channel>
</rss>